DMARC policies

DMARC setup is a control loop: authenticate your mail, publish an observation policy, read what receiving servers see, and tighten the action. DMARC can pass with one aligned path; both SPF and DKIM do not need to pass.¹ Find that working path for every legitimate sender before asking receivers to reject mail.

Before you publish

Map every sender that uses your domain and check how it authenticates. Legitimate mail needs a path through SPF or DKIM before DMARC starts making delivery decisions.

SPF and/or DKIM must be enabled for the domain before you use DMARC.² DMARC tells receiving email servers what action to take when messages sent from your domain fail SPF or DKIM authentication.³

For each sender, ask:

• What domain appears in the MAIL FROM address?
• What domain appears in the From header?
• Does SPF authorize the source for the MAIL FROM domain?
• Do those domains align?

The MAIL FROM address transmits the message between SMTP email servers, while the From address appears as the sender in email clients.^{4, 5} SPF checks whether the message came from an authorized source for the MAIL FROM domain.⁶ DMARC checks whether the MAIL FROM and From domains align.⁷ Verify that alignment for every sender before moving on.⁸

Publish the record

Once you understand the sending paths, add the policy in DNS. Start with an observational policy so you can see which legitimate streams still need repair.

Enable DMARC by creating a TXT record in DNS.⁹ The record is a line of text added to the domain according to the domain provider's instructions.¹⁰ For a domain record, use the DMARC hostname _dmarc.yourdomain.com.¹¹

The DMARC TXT record includes a p= parameter, and p stands for policy.^{12, 13} Publish at least p=none while you confirm that alignment passes.¹⁴ With p=none, the receiving server takes no action against unauthenticated mail and sends a report to the mailto address listed in the record.¹⁵

The receiver can reject, quarantine, or deliver the message.¹⁶ A p=reject policy tells the receiving server to deny and block unauthenticated mail.¹⁷ Choose the action after you understand which messages will fail and why.

Read the reports

Use the reporting period to inventory your mail. Read what receivers saw, match each source to a legitimate sender, and repair authentication or alignment before increasing enforcement.

DMARC reports can reveal authentication issues and malicious activity involving messages sent from your domain.¹⁸ They also let you validate the results of the policy you published.¹⁹ For each reported source, ask:

• Do we recognize this sender?
• Does its SPF result cover the source?
• Does its MAIL FROM domain align with the From domain?
• Does its DKIM signature align?
• If the source is legitimate, which authentication path will keep working when the policy becomes stricter?

Pay attention to the SPF result. DMARC treats both -all and ~all as SPF failures.²⁰ A message with an SPF ~all failure and no DKIM signature can leave the DMARC policy effectively ignored.²¹

Tighten enforcement

Change the policy only after the reports give you a clean view of legitimate traffic. Move from observation to enforcement based on what you have confirmed, not what you expect the sending setup to do.

Use the reports to separate senders that need a DNS or authentication fix from messages that should be handled by the policy. When a message fails SPF or DKIM, receiving servers check the DMARC record and determine whether to reject it, quarantine it, or deliver it normally.²²

If legitimate traffic still fails, fix its SPF coverage, DKIM signing, or alignment and keep observing. When the legitimate paths pass, choose the receiver action that matches your tolerance for unauthenticated mail. A strict reject policy can protect the domain from unauthenticated messages claiming to be from it, while quarantine gives the receiver a different handling instruction.¹⁶

What not to do

Avoid these configuration mistakes:

• Do not enable DMARC before SPF and/or DKIM are set up, because messages sent from the domain will probably have delivery issues.²³
• Do not assume an SPF ~all failure gives the receiver an effective DMARC policy when the message has no DKIM signature; the policy is effectively ignored in that case.²¹
• Do not assume a DMARC record for the parent domain affects only that domain. It applies to all subdomains unless a specific subdomain has its own DMARC record.²⁴