Start with an inventory of every sending service
The first step is finding out what sends email for your domain. That may include Microsoft 365 or Google Workspace, a website contact form, a CRM, accounting software, appointment reminders, marketing platforms, shipping notifications, and support tools. If one legitimate sender is left out, its messages can fail after SPF or DMARC is tightened. If unknown senders are included, your policy may trust more systems than necessary.
I review your DNS records and map known sending services before changing anything. This is especially important after a website migration, rebrand, staff change, or move between email providers. The goal is a sending inventory that reflects how your business actually communicates, rather than a copied record containing old vendors, duplicate SPF entries, or broad permissions that are difficult to audit later.
- List every platform that sends as your domain
- Confirm which mailbox provider handles employee email
- Remove retired vendors from the plan before enforcement
SPF authorizes approved sending servers
Sender Policy Framework, or SPF, is a DNS record that lists the services allowed to send mail for your domain. When a receiving provider checks a message, it can compare the sending server with that published policy. SPF is useful, but it has limits: it can become difficult to maintain when many services are added, and it does not by itself prove that the visible From address has not been imitated.
A careful SPF setup uses one valid SPF record and includes only the providers you intentionally authorize. Multiple SPF records can create evaluation problems, while an overly broad policy can expand your trusted sending surface. I check syntax, included services, redirects, and obsolete entries, then document what each authorization is for so a future software change does not turn DNS maintenance into guesswork.
- Publish one SPF policy for the domain
- Keep authorized services narrow and current
- Recheck SPF after adding a new email platform
DKIM adds a signature to outgoing messages
DomainKeys Identified Mail, or DKIM, lets an email service sign outgoing messages with a private key. The matching public key is published in DNS, allowing receiving systems to verify that the message was signed by an authorized service and that important signed content was not changed in transit. DKIM is configured inside the sending platform, so the exact selector and DNS record depend on the provider.
DKIM becomes more valuable when several services send on your behalf. Each provider may require its own selector, and a website platform or marketing tool may need separate setup from your primary mailbox service. I verify that signatures are actually appearing on messages, not merely that a DNS record exists. I also check alignment with the visible From domain, because authentication that passes but does not align may not provide the result you expect under DMARC.
- Generate or enable DKIM in each sending platform
- Publish the provider’s selector record accurately
- Verify signed messages and domain alignment
DMARC turns authentication into a policy
Domain-based Message Authentication, Reporting, and Conformance, or DMARC, connects SPF and DKIM to the domain people see in the From line. It can provide reports about authentication results and gives domain owners a policy choice for messages that fail alignment. A practical rollout often starts with monitoring, because reports can reveal forgotten systems before enforcement affects legitimate mail.
Once the sending inventory is understood, DMARC can be strengthened deliberately. The available policy levels are monitoring, quarantine, and reject, but the right setting depends on your actual senders and business tolerance for false positives. We help you interpret failures, distinguish a real abuse attempt from a misconfigured vendor, and choose a path that improves protection without blindly blocking invoices, form notifications, or customer replies.
- Begin with reporting when your sending sources are unclear
- Review failures by source and authentication method
- Increase enforcement only after legitimate senders pass
Meet modern sender expectations without chasing inbox tricks
Google and Yahoo have published sender requirements that make email authentication increasingly important, particularly for organizations sending higher volumes. Requirements and enforcement can vary by sender type and volume, but the practical foundation is consistent: authenticate your domain, maintain accurate DNS, use sound sending practices, and make it possible for recipients to manage unwanted messages where applicable.
Authentication cannot repair every deliverability problem. Poor list hygiene, misleading content, compromised accounts, or a damaged sending reputation can still affect placement. I focus on the technical foundation first, then explain what your team or email platform must manage going forward. You receive a clear record of the settings, known senders, unresolved risks, and the next review point instead of a vague promise that every message will land in the inbox.
- Separate authentication work from content and reputation issues
- Use provider guidance for current sender requirements
- Keep DNS ownership and access with your business