DMARC

Tell receiving mail servers how to handle messages that fail authentication — protecting your domain from spoofing.

DMARC lets you tell receiving mail servers how to handle messages that fail authentication checks for your domain — protecting your domain from being used in phishing and spoofing attacks.

How it works with eusend

DMARC passes when either DKIM or SPF is aligned with your sending domain — it doesn't require both. Because eusend signs every outbound email with your own DKIM key (set up during domain verification), DKIM alignment passes automatically. You can add a DMARC record to your domain straight away without any additional infrastructure changes.

Add a DMARC record

Add the following TXT record to your domain's DNS. Start with a p=none policy so you can monitor results before enforcing anything.

Type	Host / Name	Value
`TXT`	`_dmarc.acme.com`	`v=DMARC1; p=none; rua=mailto:dmarc@acme.com;`

ℹ

Replace dmarc@acme.com with a real address you control. Receiving servers send aggregate reports to this address — XML digests of authentication results across all email from your domain, typically once a day.

Tightening the policy

Once you've confirmed your emails are passing DMARC (check the Authentication-Results header in any received email, or wait for aggregate reports), you can switch to a stricter policy:

Policy	Effect
`p=none`	No action taken. Reports are still sent. Use this while monitoring.
`p=quarantine`	Failing messages go to spam. A good middle ground once delivery is confirmed.
`p=reject`	Failing messages are bounced outright. Maximum protection.

✦

Only move to p=reject once you're certain all legitimate email from your domain passes DKIM or SPF. Any service sending on your behalf — transactional email, marketing tools, CRMs — needs to be authenticated before you enforce rejection.

DMARCbis: the updated standard

In May 2026 DMARC was revised and promoted to a full IETF standard — DMARCbis (RFC 9989–9991, replacing the original RFC 7489). Nothing you've already published breaks: the record eusend generates uses only long-stable tags and is fully DMARCbis-compatible. A few tags did change, though.

Deprecated tags — don't add them

Tag	Status
`pct`	Removed. Percentage-based enforcement is gone; use `t=y` (below) for testing instead.
`rf`	Removed. Reports are XML-only.
`ri`	Removed. Receivers choose their own report interval.

If an older tutorial tells you to add pct=100, skip it — it's a no-op that some validators now flag.

`np` — block non-existent subdomains

The headline DMARCbis addition is np, a policy for mail from subdomains that don't exist. Attackers love spoofing addresses like billing.acme.com even when you've never created that subdomain. Because a non-existent subdomain never sends legitimate mail, you can set np=reject safely — even while your main policy is still p=none for monitoring:

Type	Host / Name	Value
`TXT`	`_dmarc.acme.com`	`v=DMARC1; p=none; np=reject; rua=mailto:dmarc@acme.com;`

np only applies to subdomains with no DNS records at all. A sending subdomain you've verified in eusend (it carries a DKIM record, so it "exists") is unaffected and follows your sp/p policy instead.

`t` — testing mode

t=y marks a policy as testing: receivers evaluate p/sp/np and send reports but take no action, the way pct=0 used to. Use it to trial a stricter policy without risking delivery, then remove it to enforce.

ℹ

These tags are optional hardening. The record eusend gives you at domain verification already follows the safe p=none → p=quarantine → p=reject path; adding np=reject is the one change worth making early, since it costs nothing and closes the subdomain-spoofing gap.