term · dmarc check

How do you run a DMARC check for application email?

A DMARC check should verify four separate things: a valid policy can be discovered in DNS, its required tags parse correctly, at least one authenticated SPF or DKIM identifier aligns with the visible From domain on a real message, and every legitimate application sender is represented before enforcement. Query the _dmarc name, inspect the record, then examine message authentication results from controlled sends. A DMARC pass validates authorized domain use; it does not prove delivery or inbox placement.

Treat a DMARC check as four tests, not one lookup

A useful check has four layers. First, discover the policy that applies to the message's author domain. Second, validate the TXT record as a DMARC policy rather than accepting any text returned by DNS. Third, test identifier alignment on an actual message: the SPF-authenticated MAIL FROM domain or a verified DKIM signing domain must align with the domain in the visible From header. Fourth, confirm operational coverage by sending through every legitimate application, provider, region, and message class that uses the domain. A green DNS lookup covers only part of the first two layers. It cannot show that a provider signs with the intended domain, that a custom return path is active, that forwarding changed SPF behavior, or that an overlooked system will survive an enforcement policy.

Query the correct DNS name and follow policy discovery

Start with the exact domain in the RFC5322 From header, often called the author domain. Query TXT at _dmarc followed by that domain. For a message from alerts@notify.example.test, begin at _dmarc.notify.example.test rather than the website host, MX host, or return-path domain. RFC 9989 defines policy discovery beyond a single lookup: if the author domain has no valid record, a receiver can walk the DNS tree to find the applicable organizational or public-suffix policy. Subdomain handling can come from the sp, np, or p tag depending on what exists and where the policy is found. This means a checker should report both the queried name and the policy domain it actually selected. A result that merely says record found can hide inheritance mistakes or an explicit subdomain policy that changes the expected treatment.

Validate record structure before interpreting policy

A DMARC policy record uses tag-value syntax. Under RFC 9989, v=DMARC1 is required, is case sensitive, and must appear first; a valid p tag supplies the requested assessment policy. Common policy values are none, quarantine, and reject. Optional tags describe reporting destinations, subdomain behavior, and strict or relaxed SPF and DKIM alignment. Do not silently repair misspelled tags, a missing p value, duplicate or conflicting records, invalid separators, or a value copied with DNS-provider quoting artifacts. Treat a permanent evaluation error as a result that needs correction, not as a DMARC pass or fail. Also distinguish a transient DNS lookup error from a malformed record. Retry a transient resolver failure through a controlled path, but do not claim the domain has no policy until authoritative DNS can be queried reliably.

Check SPF and DKIM alignment on a real message

DMARC is evaluated against message authentication, not DNS configuration in isolation. For SPF, compare the authenticated MAIL FROM domain with the visible From domain. For DKIM, compare each successfully verified signature's d= domain with the visible From domain. Relaxed alignment accepts domains with the same organizational domain; strict alignment requires identical domains. A message passes when at least one authenticated identifier passes its underlying mechanism and aligns. For example, a provider return path can make SPF pass for the provider's domain but remain unaligned with billing.example.test. If DKIM verifies with d=example.test under relaxed alignment, the message can still pass DMARC. Capture the raw Authentication-Results header from controlled recipient accounts, but interpret it in context because it reports the evaluating receiver's result and can contain multiple hops or signatures.

Read pass, fail, none, and error results precisely

A DMARC pass means a policy record applies and an authenticated SPF or DKIM identifier aligns with the author domain. A fail means a policy applies but no aligned authenticated identifier exists. None means no applicable policy was discovered. Permerror and temperror indicate errors during DMARC evaluation; a message with a DNS error cannot be considered to pass or fail DMARC. These results do not say where the mailbox provider placed the message. RFC 9989 explicitly limits a pass to validation that the domain owner's use was authorized; it does not assert that the message is safe, wanted, reputable, or inbox-worthy. Keep provider acceptance, receiving-server acceptance, DMARC result, complaint signals, and observed placement as separate fields in diagnostics and dashboards.

Map every legitimate sender before enforcement

Inventory all systems that place the domain in From: production applications, authentication emails, billing notices, support tools, marketing platforms, monitoring alerts, CRM workflows, regional accounts, and emergency systems. For each stream, capture the visible From domain, MAIL FROM domain, DKIM d= domain and selector, provider account, owner, message class, and expected volume. Send controlled messages through the normal production path and verify both authentication and alignment. Aggregate DMARC reports can reveal sources using the domain, but they need interpretation and may include forwarding or unauthorized traffic. Begin with monitoring while the inventory is incomplete, then remediate legitimate unaligned streams before requesting stronger receiver handling. Do not change a shared organizational policy only to make one application green, and do not move to enforcement based on a single test message.

Diagnose common application-email failures

If no policy is found, verify the DNS zone and record name before editing the value. If the record has a permanent error, reduce it to one valid policy and check tag ordering and syntax. If DKIM fails, inspect whether the expected selector exists, whether the provider actually signed the tested message, whether the body or signed headers changed in transit, and whether the verified d= domain aligns. If SPF passes but DMARC fails, compare the MAIL FROM domain with the visible From domain rather than treating any SPF pass as sufficient. If only forwarded mail fails, remember that forwarding often changes the envelope path and can break SPF while a valid aligned DKIM signature may survive. If a rollout causes rejection, preserve the failing headers and receiver response, stop further policy escalation, and fix the responsible stream instead of weakening unrelated authentication controls.

Apply provider-specific alignment rules deliberately

Third-party senders need configuration that binds their authenticated identifiers to a domain the organization controls. Amazon SES documents two routes: an aligned custom MAIL FROM domain for SPF and an aligned DKIM signing domain. Its default provider-owned return path may authenticate with SPF without aligning to the visible From domain, so DKIM is often the practical aligned mechanism unless a custom MAIL FROM domain is configured. Other providers use different names for return paths, bounce domains, domain authentication, and signing identities. Verify the exact output message rather than assuming a dashboard's verified badge establishes DMARC. Current Gmail sender guidance also requires authentication and alignment for applicable traffic and recommends DMARC reporting. Receiver requirements and provider features can change, so recheck their official documentation at launch and during incident review.

Use provider evidence without treating it as a DMARC verdict

SendHQ supports verified-domain sending, delivery events, suppressions, and a web dashboard. Use its sending-domain and delivery information to investigate a message stream, then verify DMARC from the receiver's Authentication-Results header and separate SPF, DKIM, and alignment evidence. Provider acceptance and delivery events do not prove inbox placement.

Record an auditable DMARC check result

A durable result should contain the author domain, query time, resolver, queried _dmarc name, selected policy domain, exact normalized record, policy and alignment modes, DNS status, and whether parsing produced passable syntax, permerror, or temperror. Add one row per controlled message with a non-sensitive message identifier, sending system, visible From domain, authenticated SPF domain and result, verified DKIM domains and selectors, alignment decisions, final DMARC result, and receiver. Keep raw headers in restricted storage because they can expose addresses, routing details, and internal identifiers. Link each finding to an owner and remediation date. Recheck after DNS TTLs expire, provider configuration changes, key rotation, new message streams, or policy escalation. This evidence makes the check reproducible and prevents a screenshot or tool badge from becoming permanent proof after the underlying configuration changes.

Frequently asked questions

Where should a DMARC record be checked?

Begin with TXT at _dmarc plus the exact domain in the visible From address. Also identify the policy domain selected through current DMARC discovery rules, because an organizational or subdomain policy may apply when the first queried name has no valid record.

Does finding v=DMARC1 mean DMARC passes?

No. It only contributes to a valid policy record. A message passes after SPF or DKIM authenticates with a domain aligned to the visible From domain. Test a real message and inspect the receiver's authentication results.

Can DMARC pass when SPF is unaligned?

Yes. A successfully verified DKIM signature can produce the aligned authenticated identifier needed for DMARC. The reverse is also possible: aligned SPF can support a pass when DKIM does not, although relying on only one mechanism reduces resilience.

Does a DMARC pass prove inbox placement?

No. It validates authorized use of the author domain for that message. A receiver can still apply reputation, content, recipient, abuse, and local-policy signals when accepting, rejecting, quarantining, or categorizing the message.

Should an application move directly to p=reject?

Usually not without inventory and monitoring evidence. Map every legitimate sender, validate alignment on controlled messages, review aggregate reports, remediate failures, and coordinate policy changes with the domain owner before requesting stronger handling.

What should be rechecked after switching email providers?

Recheck the policy discovered for each From domain, the provider's MAIL FROM and DKIM domains, selector DNS, SPF and DKIM results, relaxed or strict alignment, aggregate reports, and every controlled application message class before increasing production traffic.

Sources