Overview
Email authentication helps receiving systems evaluate whether a message is authorized to use a domain identity. SPF, DKIM and DMARC perform different jobs and work together. None guarantees that a message is harmless or that an employee account has not been misused. A practical email security review starts with the real sending systems and the identities they use, then checks whether published records support those arrangements.
Configure SPF and DKIM for every sending service and publish DMARC, even below bulk-sender thresholds. Since February 2024, Google and Yahoo have required bulk senders to use SPF and DKIM and publish DMARC with at least p=none. Google applies its bulk requirements at about 5,000 messages a day to personal Gmail accounts; Yahoo describes significant volume without a fixed public numeric threshold. These are authentication requirements, alongside other delivery rules. Inventory business mail, support, invoicing, marketing and application notifications before changing enforcement.
SPF authorizes sending infrastructure
SPF is published as a DNS TXT record and evaluates the connecting sender against a domain used by the SMTP transaction, commonly the envelope sender. It is not a direct authentication of the visible From address. RFC 7208 defines mechanisms, qualifiers, processing limits and error behavior. Publish one SPF policy record at a given owner name rather than separate policies for each vendor.
End SPF with -all once all legitimate sources are confirmed; use ~all during a monitored transition when sender inventory is still being reconciled. Never use +all or bare all: both authorize every sender. Keep SPF evaluation within 10 DNS-querying mechanisms and modifiers, counting nested include and redirect evaluation, as RFC 7208 section 4.6.4 requires. The count covers include, a, mx, ptr, exists and redirect; ip4, ip6 and all do not consume that budget. Exceeding the limit produces permerror, not stronger protection.
The example limits authorization to one documentation address, so replace it with your actual sender configuration before publishing. If your provider supplies an include, merge it into the single policy and check the complete lookup chain before release. Review provider changes for new nested lookups. Do not assume that one visible include means one lookup, or replace provider-managed ranges with copied IP addresses unless you can maintain those ranges as they change.
Illustrative only, using a documentation address:
example.com. TXT "v=spf1 ip4:192.0.2.10 -all"
Bad: authorizes every sender
example.com. TXT "v=spf1 +all"DKIM signs messages using selector-specific keys
DKIM attaches a cryptographic signature to selected message headers and a representation of the body. The signature identifies a signing domain and a selector. A receiver retrieves the corresponding public key at selector._domainkey.signing-domain and verifies the signature. DNS key presence alone does not prove that real messages are being signed or that signatures survive the actual delivery path.
A domain-only form cannot reliably discover the selectors used by every sender. Obtain selectors from provider settings or legitimate message evidence rather than guessing common names. The illustrative owner name s1._domainkey.example.com could hold a TXT key record or point through a provider-managed CNAME arrangement. The correct record type and destination depend on the mail service’s documented configuration.
Use DKIM RSA keys of at least 2048 bits where your provider supports them, consistent with RFC 8301 recommendations. Enable signing and verify representative messages before retiring an old selector. Rotate keys through the provider process: publish the new selector, allow DNS propagation, switch signing, then retain the previous public key while older messages can still be verified. Assign a rotation owner and follow the provider schedule; rotate promptly after suspected private-key exposure. Publish only the public key, never the private signing key.
Provider-managed DKIM CNAME pattern for example.com:
s1._domainkey.example.com. IN CNAME s1.dkim.mail-provider.example.com.
Both names are illustrative. Replace the selector and target with the exact values supplied by your provider; do not invent a public key or mix TXT and CNAME at the same owner name.DMARC connects authentication to the visible From domain
DMARC checks alignment between the domain in the visible From header and a domain authenticated through SPF or DKIM. At least one aligned authentication path must pass. A valid DKIM signature for an unrelated vendor domain does not automatically satisfy alignment for example.com. Forwarding and message modification can affect the two paths differently, so test representative delivery arrangements rather than assuming DNS records settle the question.
The DMARC policy is a TXT record at _dmarc.example.com. The p tag expresses the requested handling for messages that fail DMARC: none, quarantine or reject. A p=none record supports monitoring but does not request quarantine or rejection. The pct tag can limit application of the requested policy. Receivers apply their own local handling, so a published policy is not a guarantee of universal delivery behavior.
Roll out DMARC in stages using the policies RFC 7489 defines: p=none with rua aggregate reporting, then p=quarantine, then p=reject. Create and monitor the reporting mailbox first. Review reports across a representative business cycle, fix legitimate sender alignment and check infrequent billing or account-recovery messages before advancing. Start quarantine on a portion of traffic if helpful, then expand to full enforcement before reject. Receivers choose their own handling. If legitimate mail breaks, return to the previous stage while fixing alignment; keep reporting active and authorize external report destinations when required.
Stage 1, monitor example.com with an owned reporting mailbox:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Stage 2, after sender alignment is verified:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"
Stage 3, after quarantine results are reviewed:
_dmarc.example.com. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"
Publish one stage at a time, replacing the previous record.What to check
Match each business sender to its envelope domain, DKIM signing domain and visible From domain. Confirm who controls the corresponding DNS records and whether the provider manages key rotation. Keep separate evidence for inbound routing and outbound authentication. MX records describe inbound destinations; they do not establish that messages sent by a marketing platform pass SPF, DKIM or DMARC.
Review the published SPF policy for duplicates, overly broad authorization and provider dependencies. Inspect DMARC for one coherent policy and an intentional enforcement stage. Retrieve DKIM keys using selectors supplied by the legitimate sender configuration. Where authorized, inspect representative message authentication results with the mail administrator, minimizing stored personal data and preserving only the evidence necessary for the review.
Plan changes with a rollback and delivery verification procedure. Include transactional messages that may be infrequent, such as password resets and billing notices. Verify behavior at representative receivers without treating a single successful delivery as proof for all recipients. Document remaining exceptions and assign owners. Recheck the inventory when a team adds a vendor or changes its From domain.
Common mistakes: confusing published records with authenticated mail
One SPF record can look reasonable while exceeding lookup limits through nested includes. A DKIM key can exist for a retired sender that no longer signs anything. A DMARC reject policy can coexist with broken legitimate delivery. These are different questions from DNS presence and require evidence from the actual mail workflow. Avoid describing a domain-only check as a complete email authentication test.
Another mistake is treating non-sending domains as irrelevant. A parked domain can still be impersonated in visible addresses. Discuss intended mail use with the owner and publish appropriate non-sending policies where suitable. A null MX declaration concerns inbound mail; it does not replace outbound anti-spoofing policy. Keep each DNS record’s purpose distinct when explaining the work to non-specialists.
How the free Meo audit checks this
Meo queries TXT at the registered domain for SPF and at _dmarc for DMARC. SPF attention covers missing or multiple policies and an all-senders-authorized mechanism. The instant check does not fully validate syntax, resolve include chains, calculate lookup limits or test sending infrastructure. A pass describes that limited observation rather than verified authorization of real messages.
DMARC checks recognized policy and percentage fields, with attention for monitoring-only or partial enforcement, missing records and certain invalid combinations. It does not validate the full grammar, alignment, reporting destinations or receiver behavior. MX is informational context. DKIM remains unknown because the instant audit does not guess selectors or send email. The broader review must obtain legitimate selector and sender evidence before making stronger conclusions.
Frequently asked questions
Does SPF authenticate the visible From address?
Not directly. SPF evaluates an SMTP domain identity. DMARC adds the alignment relationship to the visible From domain, using a passing aligned SPF or DKIM result.
Can I publish two SPF policies for two vendors?
Publish a single SPF policy at that DNS owner name and incorporate authorized services appropriately. Multiple SPF policy records can cause a permanent error. Check provider dependencies and lookup limits before deployment.
Why is DKIM unknown in the instant audit?
DKIM keys use sender-selected selector names. The audit does not guess them. A legitimate selector from provider configuration or message evidence is needed, and a public key alone would not prove real-message signing.
Is p=none a broken DMARC record?
It can be a valid monitoring policy. It does not request quarantine or rejection. The right next step is to review legitimate sender alignment and rollout readiness rather than forcing enforcement without preparation.
Do these records prevent every phishing message?
No. They do not stop all lookalike-domain abuse, malicious content or misuse of a legitimate account. Email security also needs account protection, filtering, user processes and incident handling beyond these public records.
Sources and review dates
Content reviewed against the instant audit’s implemented checks and the references below. This is a content review date, not a new revision date for these standards. Confirm provider-specific settings with the responsible administrator before deployment.