Email authentication should show which services may send for a domain, prove that important messages were signed, and tell receiving systems what to do when authentication fails. This checklist helps an owner review that chain before moving to stronger enforcement.
SPF, DKIM, and DMARC solve different parts of the authentication problem. A record can exist and still provide weak protection if legitimate senders are missing, domains do not align, or enforcement is enabled before business systems are ready.
SPF identifies which servers may use a domain in the technical return path. It should represent current sending services without duplicate records, excessive DNS lookups, obsolete vendors, or an unnecessarily broad authorization.
DKIM lets a receiving system verify that a message carries a valid cryptographic signature for a signing domain. The audit checks selector visibility, alignment, key-management dependencies, and whether important senders actually sign.
DMARC compares the visible From domain with SPF and DKIM results, provides aggregate reporting, and publishes a policy for failed mail. It can pass through aligned SPF, aligned DKIM, or both.
The goal is a controlled list of legitimate senders, not the longest possible record.
| Check | Evidence to review | Why it matters |
|---|---|---|
| One SPF record | Confirm that the domain publishes a single valid SPF policy rather than multiple competing TXT policies. | Multiple SPF records can produce a permanent error and make legitimate mail fail authentication. |
| Sender inventory | Map Google Workspace, Microsoft 365, support platforms, marketing tools, invoicing systems, forms, and transactional services. | A forgotten platform may fail after enforcement, while an obsolete include leaves unnecessary authorization. |
| Lookup pressure | Review include, redirect, a, mx, and exists mechanisms that contribute to DNS lookup limits. | Nested vendor records can push SPF beyond the permitted lookup budget even when the visible record looks short. |
| Return-path alignment | Compare the technical envelope domain with the domain shown in the From address. | SPF can authenticate a service but still fail DMARC alignment when the two organizational domains differ. |
| Ending mechanism | Document whether the policy ends in neutral, soft fail, or fail and whether that choice matches the rollout stage. | The final mechanism communicates how non-authorized infrastructure should be treated during SPF evaluation. |
A public selector record is only one part of the review. The business also needs evidence that real outbound mail uses the expected signing domain.
List the selectors assigned by each active sending platform and confirm that their public keys resolve under the correct domain. Missing or mistyped selectors should be traced to the responsible platform.
Compare the DKIM signing domain with the visible From domain. Strict DMARC alignment requires an exact match; relaxed alignment permits the same organizational domain.
Record who controls key generation, rotation, selector retirement, and DNS publication. The public audit does not retrieve private keys or access sending accounts.
DMARC should progress from visibility to enforcement only after legitimate traffic is understood.
| Check | What to confirm | Safe next step |
|---|---|---|
| Policy is published | The record has valid version, policy, percentage, alignment, and reporting tags with no conflicting DMARC record. | Correct syntax before drawing conclusions from report volume or policy behavior. |
| Aggregate reports arrive | The authorized reporting mailbox receives XML summaries from major providers and the team knows who reviews them. | Group records by source, count, SPF result, DKIM result, and alignment before changing policy. |
| Legitimate sources pass | Business systems are recognized and pass through aligned DKIM, aligned SPF, or both. | Fix unexplained failures and remove obsolete sources from the approved inventory. |
| Subdomains are considered | The owner understands whether the main policy should also cover active and inactive subdomains. | Document every legitimate subdomain sender before applying a stricter subdomain policy. |
| Enforcement is staged | Monitoring data supports the move from none to quarantine and then reject. | Use a controlled percentage and rollback plan instead of making an immediate all-domain change. |
A DMARC report is telemetry, not automatically an incident alert. It summarizes messages a receiving provider observed for the domain during a reporting period.
Confirm the reporting organization, report ID, covered timestamps, and published domain policy. A report ID is a unique reference, not an error code.
For each source IP, compare message count, visible From domain, DKIM signing domain, SPF return-path domain, authentication results, alignment, and final disposition.
A known platform with DKIM pass and SPF misalignment may be a configuration gap. An unknown high-volume source that fails both paths deserves a different priority and owner review.
The report should connect technical evidence to operational impact without claiming that every failure is an attack.
| Finding | What it may cause | Recommended response |
|---|---|---|
| DKIM passes but SPF is not aligned | DMARC can still pass, but delivery depends on one aligned authentication route. | Confirm whether the platform can use an aligned custom return path without disrupting delivery. |
| DMARC remains at p=none | Reports arrive, but receiving systems are not instructed to quarantine or reject failed mail. | Use collected evidence to prepare a staged enforcement plan after legitimate sources are clean. |
| Unknown sender fails both checks | The record may represent spoofing, an abandoned service, forwarding behavior, or an unrecorded business tool. | Investigate ownership and message volume before authorizing or blocking the source. |
| Reports are delivered but not reviewed | Authentication changes and new sending sources can remain unnoticed. | Assign an owner, review cadence, exception process, and evidence retention period. |
These answers keep the audit scope practical and safe.
Yes. DMARC needs either aligned SPF or aligned DKIM to pass. Recurring SPF failures should still be explained so the business is not unnecessarily dependent on one route.
Usually not. Inventory legitimate senders, validate alignment, review reports, correct gaps, and then move through quarantine and reject in controlled stages.
No for the standard public audit. We review DNS, authentication, routing, certificate, alignment, and report posture without reading mail or requesting passwords.
Use these pages to compare the service scope, understand related website controls, and choose the next audit step.
The $390 Domain & Email Security Audit reviews public evidence and prepares prioritized recommendations without mailbox access or automatic DNS changes.