DNS and email records explained: MX, SPF, DKIM and DMARC

Check the domain that actually sends or receives mail

An audit of www.example.com reports no MX or SPF, while your addresses use example.com. Do not copy mail records onto www to remove those findings. Compare the audited host with the mail domain using dig. These queries retain the DNS status header.

NOERROR with no requested records can be a legitimate empty answer; inspect any aliases before concluding absence. SERVFAIL indicates a failed lookup, while NXDOMAIN indicates a nonexistent name. Neither a blank short answer nor a scanner’s unknown result proves that the intended record is missing.

SiteAudit checks the exact host and _dmarc.host. It stores record counts and presence, not complete policy values, and warns about duplicate SPF or DMARC candidates. It does not discover the organizational domain, query DKIM selectors, evaluate SPF or DMARC, validate DNSSEC end to end or measure mail delivery.

dig example.com MX +noall +comments +answer
dig example.com TXT +noall +comments +answer
dig _dmarc.example.com TXT +noall +comments +answer
dig www.example.com MX +noall +comments +answer

1. List the website host, receiving domain, envelope sender and visible From domains used by each sending service.
2. Save the DNS status and answers for those names; investigate lookup failures separately from empty results.
3. Compare the records with each provider’s configuration, then validate real test messages before changing policy.

Reference: ISC BIND: dig queries and visible response status

Use MX for receiving mail, not authenticating senders

An MX answer contains a preference number and a destination hostname. Lower numbers are preferred; equal numbers can offer equivalent destinations. Verify the target names against the receiving provider’s instructions. MX does not say which services may send mail claiming your domain.

A single null MX, written as priority 0 with destination “.”, declares that the domain accepts no mail. It must not coexist with ordinary MX records. Use it only for a domain intentionally receiving nothing, not as a default fix for a warning. An absent MX is different: SMTP can fall back to the domain’s address records.

A working website proves neither that its host needs MX nor that a mailbox exists. Check incoming delivery with the provider and a controlled mailbox.

Reference: RFC 7505: null MX and domains accepting no mail

Keep one SPF policy for each sending identity

SPF authorizes sending hosts for the SMTP envelope-sender domain, usually visible as Return-Path after delivery; it does not directly authenticate the displayed From address. A sending subdomain needs its appropriate policy: it does not automatically inherit the apex SPF record.

Publish one SPF TXT record beginning v=spf1 at that name. Merge approved providers into the existing policy instead of adding a second SPF record. Multiple quoted strings inside one TXT record are not multiple policies. An include evaluates another domain’s SPF policy; use the exact include supplied by your provider.

SPF evaluation permits at most ten DNS-querying terms, including nested includes and redirects. Exceeding that limit causes permerror; counting only visible include statements is insufficient. Inventory all legitimate senders and validate the complete evaluation before changing the final all mechanism. SiteAudit does not perform that evaluation.

Reference: RFC 7208: SPF records and evaluation limits

Look up the selector used by the actual signature

DKIM lets a receiving server verify a message signature using a public key in DNS. Obtain the selector from your sending provider or the s= field in a real DKIM-Signature header; its d= field supplies the signing domain. Different senders and key rotations can use different selectors.

For an illustrative s=mail2026 and d=example.com, query the name below. Substitute the actual values instead of assuming mail2026 exists. Follow the provider’s TXT or CNAME setup, preserve the public-key value and keep private keys private.

A record does not prove mail is signed or its signature survives transit. Check the receiving system’s Authentication-Results on a controlled test message. SiteAudit cannot probe DKIM without selector input.

dig mail2026._domainkey.example.com TXT +noall +comments +answer

Reference: RFC 6376: DKIM selectors and signing domains

Align authentication before tightening DMARC

DMARC checks the visible From domain against an authenticated SPF envelope domain or DKIM d= domain under the configured alignment mode. Passing either aligned SPF or aligned DKIM is sufficient; both are not required. A successful SPF check for an unrelated provider domain alone does not establish DMARC alignment.

Start with an inventory of legitimate senders and monitoring using p=none plus a real aggregate-report destination you control or have authorized. p=none requests no DMARC-based quarantine or rejection; it does not bypass a receiver’s other filtering, and reports require reporting configuration. Review results before moving to quarantine or reject.

Check the scope of subdomain policies before tightening enforcement. DMARC policy discovery can find an applicable parent policy, which SiteAudit’s exact _dmarc.host lookup does not model. Missing records on www therefore do not establish missing protection for example.com. Recheck DNS after caches expire and validate representative messages from every sender.

Reference: RFC 9989: DMARC alignment, policy discovery and deployment