A company can have a valid business domain, an active mailbox and a working SMTP server yet still see messages delayed, rejected or sent to spam. One common reason is incomplete or misaligned sender authentication. SPF, DKIM and DMARC are different mechanisms that work together to help receiving systems decide whether a message is legitimately associated with the domain in its visible From address.
These standards are important for Microsoft 365, Google Workspace, private mail servers and third-party email platforms. They are especially relevant when an organisation sends mail through several systems: employee mailboxes, CRM, billing, website forms, customer support and transactional notifications.
First, separate delivery from authentication
SMTP handles the transport of messages between mail systems. DNS MX records identify which servers receive mail for a domain. SPF and DKIM authenticate aspects of outgoing mail, while DMARC connects authentication to the address users normally see. Those systems are related but solve different problems.
A correct MX record does not prove that outgoing messages are authentic. A successful SMTP connection does not guarantee inbox placement. Even if SPF, DKIM and DMARC all pass, receivers also consider reputation, content, sending patterns, complaints and user engagement. Authentication is necessary infrastructure, not a promise of delivery.
The first operational step is to identify every legitimate sender using the organisation’s domain. That inventory is often more difficult than adding the DNS records themselves.
SPF: which systems may send mail?
Sender Policy Framework (SPF) publishes information through a DNS TXT record. Receiving servers can evaluate whether the connecting mail system is authorised to send using the envelope sender domain. An SPF record may authorise an email provider, a dedicated IP range or another sending service through an include mechanism.
For example, an organisation may use Microsoft 365 for staff mail and a separate transaction platform for application messages. Its SPF configuration needs to account for both sources where SPF authentication is expected. Omitting one source can cause valid messages to fail checks; blindly adding every vendor creates an overly permissive policy.
SPF has practical limits. DNS lookup limits can be exceeded by chains of nested includes. Forwarding can also break SPF because the final forwarding server may not be authorised by the original domain. That is one reason DKIM and DMARC matter. Avoid publishing multiple separate SPF records for the same domain; instead maintain a single deliberate policy.
DKIM: a cryptographic signature on the message
DomainKeys Identified Mail (DKIM) adds a signature to outgoing messages. The sending system signs selected headers and content using a private key. The receiving system retrieves the corresponding public key from DNS and checks that the signature is valid.
DKIM helps receivers verify that the signed parts of the message have not changed unexpectedly and that a domain associated with the signature authorised the signing process. A DKIM signature does not establish that the sender is trustworthy in every other respect, and it does not encrypt the email contents.
Key management is important. Use sufficiently strong keys supported by the provider, protect private keys, document who can rotate them and remove old selectors when they are no longer used. Check that each outbound mail platform signs using the expected domain. Some marketing services sign with their own domain by default, which may not satisfy the organisation’s DMARC alignment requirements.
DMARC: alignment with the visible From address
Domain-based Message Authentication, Reporting and Conformance (DMARC) evaluates whether SPF or DKIM passes with the appropriate domain alignment to the message’s visible From domain. A message can pass SPF for a third-party bounce domain and still fail DMARC alignment if that domain does not align with the visible From address.
DMARC policies commonly use p=none, p=quarantine or p=reject. A monitoring policy requests reports without instructing receivers to quarantine or reject solely on the basis of the DMARC policy. Quarantine and reject express stronger preferences for failed authentication, subject to receiving-server decisions and applicable standards.
Moving immediately to p=reject without discovering all legitimate senders can disrupt invoices, support notifications and customer communications. A safer approach is to monitor reports, correct failing sources, confirm alignment and tighten the policy deliberately. The target is strong protection without blocking legitimate mail.
A typical multi-platform business problem
Consider a company whose staff use Google Workspace but whose ecommerce platform sends order confirmations through a third-party SMTP provider. The staff mail may pass SPF and DKIM correctly, while the order confirmations fail alignment because the SMTP provider uses an unrelated Return-Path domain and signs only with its own domain.
The fix is not to change the organisation’s incoming MX records. Instead, configure the transaction platform to use its supported custom bounce domain and domain-aligned DKIM signing where available, then update the DNS records supplied by that platform. Test the complete delivered message headers afterward.
A second frequent problem is a website plugin sending mail directly from the hosting server while presenting the company’s domain in the From field. The host may not be authorised by SPF, may lack DKIM signing and may have a poor sending reputation. Using an authenticated, appropriately configured mail service is usually more reliable than relying on default server mail functions.
Gmail and bulk-sender expectations
Google’s published Gmail sender guidelines distinguish general senders from those sending more than 5,000 messages per day to Gmail accounts. The bulk-sender requirements include SPF, DKIM and DMARC, relevant DNS and TLS practices, and additional requirements for marketing or subscribed messages. The rules concern messages delivered to Gmail accounts; they should not be interpreted as a universal quota for all business email.
Google also describes spam-rate expectations and one-click unsubscribe requirements for applicable promotional traffic. Exact provider rules and enforcement may change, so operational teams should consult the current sender guidelines rather than relying on an old checklist.
Microsoft publishes its own email-authentication guidance. When a business sends to multiple major providers, adopting sound authentication and list hygiene is more effective than building a separate workaround for each receiver.
What to examine in the message headers
When troubleshooting delivery, capture a complete message as received by the destination. Look for Authentication-Results showing SPF, DKIM and DMARC outcomes, along with the evaluated domains. Compare the envelope sender, DKIM signing domain and visible From address. Identify whether a forwarding service, mailing list or security gateway altered the message.
Check DNS externally as well as from the sender’s environment. DNS caching and delayed propagation can obscure recent changes. Verify DKIM selectors, policy syntax and the SPF lookup count. If the message is rejected, preserve the SMTP response code and the receiving server’s error explanation instead of relying on a vague “email not delivered” report.
A domain can pass authentication and still experience reputation-based filtering. In that case, examine sending patterns, list quality, complaint rates, shared sending IP behaviour and content. Do not keep modifying SPF records when SPF is already passing.
Use reports to discover forgotten senders
DMARC aggregate reporting helps identify systems sending messages that claim to use the domain. Interpret reports carefully: some traffic may be forged, some may be legitimate third-party services and some may reflect forwarding or mailing-list behaviour. Reports show authentication patterns, not the full business context of every message.
Maintain a register of approved mail sources, owner, domain, purpose, provider, DKIM selector and expected SPF alignment. Review the register during SaaS onboarding and offboarding. Otherwise, a new marketing or invoicing system may work for months before an enforcement-policy change exposes its misconfiguration.
A controlled rollout sequence
Inventory senders and establish an authenticated path for each one. Publish or correct SPF. Enable aligned DKIM signing. Introduce DMARC reporting, assess legitimate failures and remediate them. Move toward stronger DMARC policy only when the organisation understands the impact. Monitor deliverability after each change.
Finally, make sender authentication part of routine change management. When a team connects a new CRM, replaces its mail host or introduces a customer notification platform, authentication configuration should be a required implementation step, not an emergency repair after important messages begin disappearing.