How DMARC protects your domain and supports email delivery

When DMARC supports delivery, and when it does not

DMARC supports delivery when a legitimate sending path produces an aligned SPF or DKIM pass. It gives receivers a standard authentication result for that message, while enforcement makes unauthorized use of the visible From domain harder.

Google's Email sender guidelines require bulk senders to authenticate email with SPF or DKIM and require DMARC for messages sent from a domain that sends more than 5,000 messages per day to Gmail accounts. Those requirements show that authentication is part of current sender expectations. They do not mean that a DMARC pass guarantees inbox placement.

Use this decision rule:

• If a production message has an aligned SPF or DKIM pass, DMARC can pass for that message.
• If neither identifier aligns, DMARC fails and the receiver can consider the published policy.
• If the domain has no usable DMARC record, the receiver has no DMARC policy request from that domain.
• If a public DNS lookup shows a correct record, it still does not prove that an application is signing mail, using the intended return path, or reaching the inbox.

Do not move to p=quarantine or p=reject until the legitimate production senders using the visible From domain have been identified and tested. An unknown sender that fails DMARC can lose mail when stronger enforcement begins.

A worked DMARC record and message result

This illustrative record requests aggregate reports while asking receivers to reject messages that fail DMARC:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Do not publish this example unchanged. Use a report destination your organization controls and authorizes. RFC 9989 defines rua as the tag for aggregate report destinations.

For a message from billing@yourdomain.com, the result that matters is an aligned pass. The Authentication-Results field is the standardized header field receivers use to report authentication assessments, as defined by RFC 8601.

Authentication-Results: receiver.example;
  dkim=pass header.d=yourdomain.com;
  spf=pass smtp.mailfrom=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

This example shows both mechanisms aligned to yourdomain.com. Only one aligned SPF or DKIM pass is needed for DMARC to pass. A DNS record alone cannot establish this result. Inspect a real delivered message from the exact production path, then compare its authentication results with the record.

Your domain may also need other DNS records for its sending infrastructure. The business email DNS records guide covers the related record types without treating them as substitutes for delivered-message evidence.

What to check next

Start with the evidence you have:

• If you only have a domain name, check the published DMARC record. Confirm the hostname, tags, and policy the public DNS response shows.
• If you have a delivered message, inspect its raw headers for Authentication-Results. Compare header.from with the domain that passed SPF or DKIM.
• If you administer the sending service, verify its current authentication status and the return-path or DKIM configuration in that service's documentation or interface.
• After reports accumulate, review aggregate-report data to identify sources that fail authentication or alignment before changing the policy.

Use DMARC evidence to prepare for enforcement

A record lookup can show what the domain publishes today. The remaining question is which legitimate senders still fail alignment, and whether the domain is ready for a stronger policy.

Palisade is DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while a human reviews the evidence and applies the DNS change.

Start with Palisade

Palisade does not change your DMARC policy autonomously, guarantee inbox placement, or prove that every future message will authenticate.