DMARC

DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 7489) is the rulebook that ties SPF and DKIM together. It tells receivers: "If a message claims to be from my domain but fails SPF and DKIM, do X." X is one of three policies.

The three policies

Policy	Receiver action
p=none	Don't reject anything. Just send me reports.
p=quarantine	Send the message to spam.
p=reject	Reject the message outright.

You start at p=none to see who's sending mail from your domain (legit and otherwise), graduate to p=quarantine once you've authorized your legit senders, and end at p=reject once you're sure the only mail leaving your domain is yours.

What the DMARC record looks like

_dmarc.example.com.   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100"

• p=reject — receivers should reject mail that fails auth.
• rua — where to send aggregate reports (daily summary XML).
• pct=100 — apply this policy to 100% of failing messages.

Alignment (the part that trips people up)

DMARC requires that EITHER SPF OR DKIM passes AND the passing one aligns with the From: header domain.

Example: your email From: header says hello@janesbakery.com. SPF passes because the sending IP is in yourapp.com's SPF record (since you send through your ESP). But yourapp.com is not janesbakery.com. SPF passes but doesn't align. DMARC still fails.

To fix this, the From: domain (janesbakery.com) needs to authorize the IP directly in its own SPF record, OR you need DKIM to be signed with d=janesbakery.com (not d=yourapp.com).

Why this matters for SaaS sending from customer domains

If a customer's DMARC policy is p=reject and your mail isn't properly aligned, mail to that customer's recipients gets rejected outright. Make sure your custom-domain onboarding includes:

1. SPF that authorizes your IPs from the customer's domain.
2. DKIM signed with the customer's domain (d=acme.com, not d=yourapp.com).
3. Optional: instruction to start at p=none and only graduate to p=quarantine after a week of clean reports.