Skip to main content

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC is an email authentication protocol that works alongside SPF and DKIM to empower domain owners to express how they wish email receivers to deal with email authentication failures. Google's Email Sender Guidelines now require domains to have a DMARC record. Hence, although this topic is marked "optional," we strongly recommend that you create a DMARC record for each domain you send email from using Email API.

tip

Third party services like Cloudflare's Email Security DNS Wizard can help you to configure your DMARC record and may also provide tools that process DMARC reports from email receivers.

Setting Up DMARC

To implement DMARC for your domain:

  1. Create a DMARC DNS TXT record
  2. Add the record to your domain's DNS settings

DMARC Record Structure

DMARC records follow a semicolon-separated key=value syntax that will be familiar to developers. The example below shows a typical DMARC record for the domain example.com, illustrating all of the features you might wish to encode into your DMARC record:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:reports@example.com; ruf=mailto:forensic@example.com; pct=100; fo=1;"
  • v=DMARC1: The version of DMARC being used is version 1.
  • p=reject: The policy is set to "reject," meaning if a message fails DMARC validation, the receiving server will reject the message outright. This is the strictest policy. See below for a listing of other permitted values of the p field.
  • adkim=s: The alignment mode for DKIM is set to "strict" (s), meaning the domain in the DKIM signature must exactly match the domain in the "From" header for it to pass.
  • aspf=s: The alignment mode for SPF is also set to "strict" (s), meaning the domain in the SPF record must exactly match the domain in the "From" header for it to pass.
  • rua=mailto:reports@yourdomain.com: Aggregate reports (summary of authentication results) should be sent to reports@yourdomain.com.
  • ruf=mailto:forensic@yourdomain.com: Forensic reports (detailed reports of authentication failures) should be sent to forensic@yourdomain.com.
  • pct=100: The policy applies to 100% of messages. If this were set to a lower value (e.g., pct=50), the policy would apply to only 50% of messages.
  • fo=1: The "Failure Reporting Options" (fo) is set to 1, meaning that a failure report will be sent if either the SPF or DKIM check fails (but not necessarily both).

In summary, this DMARC record enforces a strict "reject" policy for messages that fail either DKIM or SPF checks, sends aggregate and forensic reports to specified email addresses, and applies to all messages (100%).

info

Only the p and v fields are mandatory. All other fields are optional.

Policy Options

The DMARC p (policy) tag can have the following values:

  1. p=none: No action is taken on emails that fail DMARC checks. The email is delivered as usual, but reports are still sent. This is typically used for monitoring purposes before enforcing stricter policies. If you are setting up a DMARC record for an existing domain for the first time, it is advisable to start with p=none, which is acceptable to receivers like Google.

  2. p=quarantine: Emails that fail DMARC checks are marked as suspicious and may be placed in the recipient's spam or junk folder. Very few domains use p=quarantine as there is no guarantee that receivers offer quarantine capability to their users.

  3. p=reject: Emails that fail DMARC checks are rejected outright and are not delivered to the recipient. This is the strictest DMARC policy and is advised for domain owners who wish to secure their domain against spoofing.

Implementation Notes

  1. Replace example.com above with your actual domain.
  2. Adjust email addresses for rua and ruf tags to valid addresses within your organization.
  3. Start with a cautious policy (e.g., p=none) and monitor reports before enforcing stricter policies.
  4. Regularly review DMARC reports to ensure proper email authentication and detect potential abuse.

Best Practices

  • Ensure SPF and DKIM are correctly set up before implementing DMARC.
  • Gradually increase the pct value from a lower percentage to 100% to minimize potential disruptions.
  • Use p=reject only after thorough testing and confidence in your email authentication setup.
  • Monitor rua reports to track email authentication performance and adjust policies as needed.

By implementing DMARC, you enhance your domain's email security, reduce the risk of spoofing, and gain valuable insights into your email authentication practices.