Guide: authentication
How to set up DMARC
DMARC ties SPF and DKIM to the From address your recipients see, tells receivers what to do with mail that fails, and asks them to send you reports.
Last reviewed November 4, 2026
What DMARC adds
SPF checks the envelope domain and DKIM checks the signing domain, but neither has to match the From address. DMARC (RFC 9989, which replaced RFC 7489 in May 2026) does: a message passes DMARC only when SPF or DKIM passes for a domain that aligns with the From domain.
The policy is a TXT record at _dmarc.yourdomain. Receivers read it to decide what to do with mail that claims to be from you and fails, and where to send reports about what they saw.
Alignment
With relaxed alignment (adkim=r, aspf=r, the default) the domains must share the same organisational domain: mail.example.com aligns with example.com. With strict alignment (s) they must be identical.
In practice this means your sending service must sign DKIM with your domain and, for SPF to count, use a Return-Path on your domain. One aligned pass is enough.
The record and its policies
A record starts with v=DMARC1. RFC 9989 treats a record without a p= tag as p=none, but publish p= explicitly so your intent is clear. Other tags are optional: rua= for aggregate reports, sp= for subdomains, and t=y to test a policy without asking receivers to apply it. The pct= tag of RFC 7489 was removed.
- p=none: asks receivers to take no DMARC action and only to report. Use it to see who sends as your domain; normal spam filtering still applies.
- p=quarantine: asks receivers to treat failing mail as suspicious, usually by sending it to spam.
- p=reject: asks receivers to refuse failing mail. The strongest protection against spoofing of your domain, though each receiver keeps the final decision.
v=DMARC1; p=none; rua=mailto:[email protected]A safe order to tighten the policy
Start with p=none and a rua address you read. Aggregate reports are XML files, sent about once a day by each receiver, listing the sources that sent as your domain and whether they passed.
Fix every legitimate source that fails: a forgotten newsletter tool, a billing system, a support desk. Then move to p=quarantine, watch the reports again, and move to p=reject once only unauthorised senders fail.
What mailbox providers ask for
Google asks senders of close to 5,000 or more messages a day to personal Gmail accounts to publish DMARC, and asks that the From domain align with the SPF or the DKIM domain. Yahoo asks bulk senders for a valid DMARC policy of at least p=none, and DMARC must pass.
How Mail.Land handles DMARC
DMARC is required on Mail.Land: a domain verifies only with a _dmarc record that starts with v=DMARC1 and has a p= tag, and SPF, DKIM and DMARC must all verify before it can send. The dashboard suggests a value with p=quarantine and relaxed alignment; you can publish your own policy instead.
Mail.Land signs DKIM with your domain and, once the custom Return-Path record (on by default) verifies, aligns SPF too under relaxed alignment. Mail.Land receives the DMARC aggregate reports sent to the rua address it gives you and makes their pass rate, sending sources and dispositions available through the API; add a rua address of your own if you also want the raw reports.
Sources
- RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) (checked November 4, 2026)
- RFC 9990, DMARC Aggregate Reporting (checked November 4, 2026)
- Google, Email sender guidelines (checked November 4, 2026)
- Yahoo, Sender best practices (checked November 4, 2026)
Put it into practice
Add your domain to Mail.Land and the dashboard shows the exact SPF, DKIM and DMARC records to publish.