Check authentication first
Begin with a monitored p=none policy, fix legitimate alignment failures, and decide on enforcement only after representative evidence.
DMARC requires a passing SPF or DKIM identity aligned with visible From. Test each known sender, including forms, invoices, newsletters and delegated mail, before enforcement. Assign an authorised reader for aggregate reports, which may reveal infrastructure and sending patterns.
Start with observation
Publish one TXT record at _dmarc.example.com in the authoritative zone. An illustrative starting value is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Replace both addresses with an authorised domain and a monitored mailbox; some external report destinations require extra DNS authorisation. Query dig TXT _dmarc.example.com and check that there is one valid policy.
Read reports before enforcement
Compare aggregate report sources with your sender inventory. For each legitimate stream, confirm the visible From domain, the SPF authenticated domain, the DKIM signing domain and which one aligns. Fix the sending platform or DNS where alignment fails. Reports are aggregate signals, not copies of message content, and may be delayed or incomplete. Send direct test messages from each service as a second check.
A newsletter whose SPF domain is sender.example.net can still pass DMARC for example.com if a valid DKIM signature uses aligned d=example.com; confirm that in a received header.
Decide whether enforcement is ready
After reviewing reports over a period that represents all authorised mail streams, the domain owner can decide whether to test enforcement on a separately managed pilot subdomain. A policy published at _dmarc.test.example.com applies to that subdomain; it is not a percentage of mail from example.com. RFC 9989 removed the old pct tag, so do not rely on percentage-based enforcement for one domain. Before changing the main domain to p=quarantine, verify legitimate senders and forwarding paths with reports and direct messages, then monitor the outcome. Receivers make final handling decisions. RFC 9989 cautions against p=reject for general-purpose email because legitimate indirect mail can be affected; it is not an automatic next step. Keep a rollback copy of the previous record. The domain owner approves policy changes; Novasean can help interpret results for Novasean-hosted mail, while third-party senders must correct their own configuration.
Read an alignment result
Consider a message with visible From: invoices@example.com, spf=pass smtp.mailfrom=bounces.sender.test and dkim=pass header.d=example.com. The SPF pass is for a different organisational domain, but the DKIM pass aligns with the visible From domain, so DMARC can pass. If both authenticated domains differ from the visible From domain, DMARC fails even though each authentication method may pass on its own. Compare the actual domains in the recipient's Authentication-Results; do not infer alignment from a DNS checker alone.
Mail forwarding commonly changes the connecting IP, so the forwarded copy can fail SPF. A valid aligned DKIM signature can still provide a DMARC pass if forwarding has not changed signed content. Mailing lists and gateways that modify messages may break DKIM too. Test these routes before enforcement rather than treating every report source as an attacker.
A reversible rollout
| Stage | What to check | When to advance |
|---|---|---|
| Inventory and p=none | All known senders, report destination and direct-message headers | Normal traffic appears in reports and legitimate sources align. |
| Optional pilot subdomain | Mail using that subdomain, its own DMARC policy, forwarding and support reports | The pilot represents a real bounded stream and no legitimate failures remain unexplained. |
| Main-domain policy decision | All authorised streams, intermediaries, receiver behaviour and rollback | The domain owner accepts the impact after a representative review. |
RFC 9989 recommends starting with p=none and analysing aggregate reports before enforcement. A pilot subdomain is suitable only when the owner can identify and manage its actual sending stream; it does not limit policy application to a fraction of messages from the main domain. The example p=none value in this guide is a starting template, not a change to make without a monitored mailbox. Record the previous TXT value and TTL before each change. To roll back, restore that value at the authoritative zone and verify it there; previously cached policy can remain until its TTL expires.
Failure questions to answer
Why did DMARC fail if SPF passed? Compare the SPF domain with the visible From domain. A third-party sender's bounce domain often differs.
Can I publish two DMARC policies? No; keep one TXT policy at the exact _dmarc name for the domain.
Why are reports still arriving after rollback? Reporting and DNS caches are delayed. Compare the report period with the time of the change.
Will p=reject block all spoofing? It is a receiver policy request and does not replace account security, monitoring or safe handling of lookalike domains.
Does a quiet report period prove every sender is safe? No. Include infrequent billing, seasonal and forwarded mail before enforcement.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.