Business email fails on authentication: separate SPF, DKIM, DMARC, and alignment

EDITORIAL PRACTICE

Authentication is three separate promises

SPF publishes, in DNS, the list of servers allowed to send mail for a domain. Receivers compare the connecting IP address against that list and can spot mail from unauthorized servers. DKIM attaches a digital signature proving the message was not altered in transit and identifying the signing domain. DMARC builds on both: it tells receivers what to do when authentication fails, and it provides reports about the results.

The three play different roles. SPF and DKIM are mechanisms of proof; DMARC is the mechanism that decides consequences and reporting. Partial states are common: SPF configured and forgotten, a DKIM key created but never rotated, a DMARC record stuck at the monitoring policy of none. When delivery problems appear, the first step is to separate which of the three is missing and which is stale.

Google's guidelines also specify that DKIM keys should be at least 1024 bits, with 2048 bits recommended. Seemingly minor details like key length matter later, during audits and migrations. Authentication settings are assets to inventory and renew, like certificates and keys, not one-off chores.

In practice, weak authentication shows up as intermittent delivery: the same message lands in one inbox and in spam in another, depending on the receiver's policy. That inconsistency is exactly why the investigation should start from the authentication state itself rather than from anecdotal delivery reports.

It also helps to separate authentication from encryption and from deliverability. SPF, DKIM, and DMARC prove who sent a message; they are a different layer from transport encryption such as TLS and from the quality of the content. Perfect authentication does not fix a stale recipient list, and polished copy does not save unauthenticated mail from rejection. In incident work, keeping the layers apart is the shortcut: read receiver response codes, authentication results, and spam rates as separate evidence owned by separate layers.

The guidelines ask for more than authentication. Easy opt-out, one-click unsubscribe, encrypted transport, and consent-based list management all shape deliverability. Authentication is the gate; the quality of sending behavior after the gate feeds back into future delivery decisions. Reviewing how recipient lists are acquired and how consent is recorded, alongside authentication, is what makes the delivered state sustainable.

Sources: [1]

EDITORIAL PRACTICE

Passing authentication is not enough: alignment decides DMARC

The most overlooked piece is alignment. Under DMARC, the domain in the From header must align with either the SPF-authenticated domain or the DKIM signing domain. A message can be sent from a legitimate server and pass SPF and DKIM individually, yet still fail DMARC if neither domain matches the From domain.

The typical case is a third-party sending service. With vendor defaults, the envelope sender or the DKIM signature often belongs to the vendor's domain, not yours. To the user it looks like your company's mail; to authentication it is someone else's. Google's DMARC setup guide explicitly asks senders using third parties to make sure the envelope sender matches their domain and that provider servers are added to the SPF record.

Alignment comes in strict and relaxed modes; relaxed also accepts subdomains. Relaxed is the default, but strict is worth considering when subdomains sit outside your control or are run by another organization. The choice is not a matter of taste; it should follow how your domains are actually administered.

For troubleshooting, take one received message and lay out three values side by side: the From domain, the Return-Path domain, and the DKIM signing domain. Once the mismatch is visible, it is clear whether the fix belongs in sending settings, in DNS, or in the vendor's custom-domain configuration.

Domain strategy is affected as well. Sending notifications from a dedicated subdomain can isolate reputation, but each domain adds its own alignment settings and report destinations. If you split domains, design which subdomain serves which system and whether DMARC policies are individual or inherited. The sp tag, which sets a separate policy for subdomains, is a useful safety net during transitions. Subdomains created ad hoc are a classic source of inventory blind spots.

A practical trap: test mail passes, but part of production traffic fails. Exceptions such as error retries routed through a different path, or attachment-bearing messages sent via an external service, leak out of both inventories and tests. Enumerate the branching conditions of your sending paths and verify one real message header per branch as part of acceptance testing.

Sources: [2][1]

EDITORIAL PRACTICE

Inventory the senders before editing DNS

The first step of an authentication cleanup is not editing DNS; it is inventorying everything that sends mail under your domains. Your own mail servers, the billing system, the CRM, marketing tools, monitoring alerts, contact forms. It is common for each department to have contracted SaaS tools that each send as your domain independently.

For each sender, record the sending servers, the envelope domain, whether DKIM signing exists and who owns the key, and the monthly volume. Editing the SPF record without this inventory risks breaking legitimate mail. SPF records bloated with includes that hit DNS lookup limits are another symptom of edits made without an inventory.

DMARC aggregate reports double as a check on the inventory. They list the servers that sent mail claiming your domain and how authentication went. A sender you did not know about appearing in a report is also a shadow IT discovery. Designing the reconciliation between the inventory table and the reports from the start keeps authentication from being a one-off project.

Record the responsibility boundaries in the table as well: who can change each sender's authentication settings, and what procedure a vendor change requires. When something breaks, work stalls in the gap between 'DNS belongs to IT' and 'the sending service belongs to the business team' unless change authority is settled during the inventory.

A practical inventory technique is to reconcile against accounting records such as invoices and contracts. Even SaaS tools the technical team has never heard of leave a payment trail. A yearly session with IT, accounting, and department administrators surfaces unknown senders from the gap between usage and payments. Combining technical discovery with the ledger is more reliable than either alone.

Sources: [2]

EDITORIAL PRACTICE

Strengthen the DMARC policy in stages, from monitoring to reject

A DMARC policy has three levels: none (monitor only), quarantine (treat as spam), and reject. Google's guide recommends starting at none to learn how your mail authenticates, then moving to quarantine or reject as understanding grows. Jumping straight to reject can block legitimate senders you have not yet discovered.

The pct tag limits the share of mail the policy applies to. Start small and raise it toward 100 percent as the passing share improves. The reports are the evidence for each step: do not strengthen the policy while failing senders remain unidentified.

The guide also states a precondition: SPF and DKIM should be authenticating messages for at least 48 hours before DMARC is turned on. If the foundation is unstable and only the policy moves ahead, you lose the ability to tell whether a delivery problem comes from authentication or from enforcement.

The end state is reject. Only when spoofed mail is reliably dropped at receivers does DMARC stop being purely a deliverability tool and become protection for your domain. Do not skip stages, but do not park at none forever either. Decide the dwell time and promotion criteria for each stage in advance, and the project keeps moving.

Staged rollout goes more smoothly when promotion criteria are numeric. For example: promote only when legitimate senders authenticate at a stable high rate in the reports and no unknown sender remains in the failure rows, verified over two weeks of reports. Also avoid stacking policy changes on top of campaign peaks or billing cycles; changes that affect deliverability should not be made when their impact is hardest to read.

Sending criticality should also inform the rollout order. Mail tied to billing and contracts hurts more when it fails than campaign mail does. Harden alignment and monitoring for critical senders first, and expand limited-percentage policy enforcement starting from them. Low-impact senders, conversely, are good candidates for validating experimental changes. Not treating all mail as one queue lowers the risk of every stage.

Sources: [2][1]

EDITORIAL PRACTICE

Monitor reports and the spam rate continuously

DMARC aggregate reports (rua) are the window into authentication health over time. Google recommends receiving them in a dedicated group or mailbox; large organizations can receive hundreds or even thousands of reports a day, so routing them to a personal inbox does not scale. Feed them into an aggregation tool and review failures by sender and share.

The other continuous indicator is the spam rate. Google asks senders to keep the spam rate reported in Postmaster Tools below 0.30 percent and to aim for 0.10 percent or lower. A rising rate usually signals something other than authentication, such as stale recipient lists or sudden volume changes. Authentication monitoring and deliverability monitoring deserve separate dashboards, reconciled when incidents occur.

Watch authentication errors as well. Unauthenticated mail may be rejected with an error such as 5.7.26. A rise of that code in sending logs means either a receiver changed policy or your own configuration changed. Aggregating errors by code and knowing the normal level makes anomaly detection much faster.

The point of monitoring is to learn about authentication drift before users report missing mail. Tie report reviews to change events: a new SaaS tool, a DNS change, a sudden volume increase. Building that check into change management keeps the system honest.

There is a routine to reading reports, too. What matters is not the absolute number of failures but the breakdown by sender and the failing share of legitimate mail. If only one SaaS tool fails, suspect vendor configuration; if only one receiving domain fails, suspect forwarding or mailing-list effects. Forwarding can break SPF by design, so failure does not automatically mean abuse. Judging by counts alone leads to misguided policy enforcement.

Reports without a named reader are reports that go unread. Monitoring becomes a function only when the rhythm is concrete: review reports in a weekly routine, notify the owner when failure thresholds are crossed, and reconcile against the inventory quarterly. Assign someone to follow guideline changes at the major receiving providers as well. A change nobody watches is indistinguishable from a sudden change.

Sources: [1][2]

EDITORIAL PRACTICE

Manage vendor sending in both contract and configuration

Much business email is sent by vendors: sending platforms, payment notifications, delivery notices, outsourced support desks. Because they send as your domain, their authentication setup directly affects your deliverability and brand protection. Put the SPF integration method, whether DKIM can sign with a custom domain, and who owns the key into the onboarding checklist and the contract.

DKIM deserves special attention: if the vendor signs with a shared domain by default, alignment fails. Check before adoption whether your own domain can sign, and decide who generates the key and publishes the DNS record. Plan key rotation as well, including how a spare key is held for the day a key must be replaced.

Offboarding is easy to forget. When a vendor contract ends, remove that sender from the SPF record and disable its DKIM selectors. Leftover authentication permissions are an open door for spoofing. Writing the removal steps into the inventory table reduces offboarding leaks.

Vendor outages and specification changes can also break authentication. Before blaming the vendor for a deliverability anomaly, confirm the facts in your own reports; and when you do contact the vendor, being able to point at the exact report rows shortens the investigation considerably.

Coordination with the security team matters as well. When phishing that impersonates your domain is observed, a reject policy and the report history become evidence for scoping the damage and explaining it externally. Authentication work looks like a deliverability chore for IT or operations, but it is also brand protection and incident-response infrastructure. Report entries showing real impersonation attempts are strong material for bringing stakeholders in.

Sources: [2]

EDITORIAL PRACTICE

Leave the working state in an auditable form

Finally, leave the authentication state in an auditable form. For each domain and subdomain: the SPF record, the DKIM selectors, the DMARC policy. The change history and its reasons, the dates of policy promotions and the report periods behind those decisions. With that record, migrations, audits, and handovers no longer start from a fresh investigation.

Bulk sender requirements keep evolving. Google required senders of 5,000 or more messages a day to Gmail to have SPF, DKIM, and DMARC, one-click unsubscribe, and spam-rate control. Requirements tend to widen over time, so adopting the high-volume rules early, even below the threshold, makes later transitions cheaper.

The review points condense to five: proof (SPF and DKIM correct, keys sound), alignment (matching the From domain), coverage (no sender missing from the inventory), strength (policy advancing on its staged plan), and monitoring (someone watching reports and rates). A state where these five can be checked separately is what 'operating' authentication means, as opposed to merely 'having configured' it.

Email is the oldest and most business-critical notification channel. Before treating non-delivery as a copywriting problem, inspect the foundation of authentication. That order is the shortest path to fewer tickets and fewer delays.

A useful record-keeping habit is to attach an export of the DNS zone or record settings to the ledger at every change. If who changed what, when, and why can be reconstructed, the decision to roll back the last change during an incident becomes fast. A small scheduled check, for example a weekly script verifying the presence and policy of SPF, DKIM, and DMARC on the main domains, also catches accidental deletions or expirations early.

Sources: [1]