Email Security Baseline: Stop Spoofing and Strengthen SPF DKIM DMARC
Email trust is no longer a “nice to have” control. Since February 2024, Google and Yahoo have required higher standards from bulk senders, and the change affects more than newsletters. It affects how customers, suppliers, staff, and partners decide whether a message from your domain is real.
The practical goal is simple: make it hard for attackers to send mail that looks like it came from your organisation, while keeping legitimate messages flowing.
That is the baseline. Not a one-off project. Not a marketing setting. A security control for every domain that sends, or could be abused to send, email.
Google and Yahoo changed the baseline in February 2024
Google and Yahoo introduced new sender requirements for organisations that send bulk email, with enforcement starting in February 2024. Google’s rules focus especially on senders that deliver large volumes to Gmail accounts, commonly described as 5.000 or more messages per day.
The core requirements include:
Authenticate email using SPF or DKIM, and publish a DMARC record.
Keep spam complaints low.
Use a working one-click unsubscribe process for subscribed messages.
Send from domains with valid DNS records.
Make sure the visible sender domain matches authenticated sending where required.
Yahoo introduced similar expectations. Together, these changes make email authentication a delivery issue as well as a security issue.
For many organisations, SPF DKIM DMARC, email authentication, business email compromise, Google Yahoo sender requirements now belong in the same baseline conversation. If the settings are missing or weak, legitimate email can be filtered, delayed, or rejected. If the settings are poorly designed, attackers can still impersonate the domain.
Spoofing and business email compromise are financial risks
Spoofing happens when someone sends an email that appears to come from a trusted domain. The attacker may use the name of a finance director, vendor, HR system, or customer support mailbox. The message may request a payment, redirect an invoice, reset a password, or convince someone to open a harmful attachment.
Business email compromise is the wider fraud pattern. It often uses spoofed or lookalike email to trick staff into authorising payments or changing account details.
The FBI Internet Crime Complaint Center (IC3) 2023 report gives this risk scale. It reported more than USD 2.900 million in adjusted losses linked to business email compromise in 2023. That figure does not include every unreported incident, and it does not measure the operational cost of recovery, legal review, customer notification, or reputational damage.
Email authentication does not stop every fraud attempt, but it removes one of the attacker’s easiest tools: sending as your domain without permission.
What SPF, DKIM, and DMARC actually do
These three controls work together. Each answers a different question.
Control | What it checks | Why it matters |
SPF | Whether the sending server is allowed to send for the domain | Helps block unauthorised mail sources |
DKIM | Whether the message has a valid cryptographic signature | Proves the message was not altered and was signed by an approved sender |
DMARC | Whether SPF or DKIM aligns with the visible From domain | Tells receivers what to do with suspicious mail |
SPF, Sender Policy Framework, lists the mail systems allowed to send for a domain.
DKIM, DomainKeys Identified Mail, adds a digital signature to messages. The receiving service checks that signature against a public DNS record.
DMARC, Domain-based Message Authentication, Reporting and Conformance, connects authentication to policy. It lets a domain owner say, “If a message fails these checks, report it, quarantine it, or reject it.”
A careful DMARC setup gives visibility before enforcement. That matters because most organisations send email from several places, such as Microsoft 365, Google Workspace, CRM platforms, helpdesk tools, e-commerce systems, payroll platforms, and marketing tools.
How to implement without breaking legitimate email
The wrong approach is to publish a strict reject policy on day one. That can block valid messages from systems that were never documented.
A better approach starts with discovery, then moves towards enforcement.
1. Inventory every sender
List every platform that sends email using your domain or subdomains. Include obvious systems and quiet ones:
Core mail platform
Marketing email provider
Website forms
Billing and invoicing systems
Ticketing and support tools
HR and payroll platforms
Security alerting tools
Third-party agencies or managed services
If a system sends as yourdomain.com , it must be covered.
2. Fix SPF with restraint
SPF records live in DNS. They should include only approved senders.
Common mistakes include adding too many services, leaving old providers in place, or exceeding the DNS lookup limit. SPF has a limit of 10 DNS lookups. If a record goes beyond that, checks can fail even when the sender is legitimate.
Keep SPF clean:
Remove unused senders.
Avoid broad includes that allow more than needed.
Use subdomains for separate services where possible.
Test before changing policy.
3. Enable DKIM for each sending platform
Most major email platforms provide DKIM setup instructions. The usual process is to create one or more DNS records, then enable signing inside the platform.
Do not assume DKIM is active because a platform supports it. Verify it.
Check that each service signs mail with the correct domain or subdomain. This alignment is what DMARC uses to decide whether the message is trusted.
4. Start DMARC in monitoring mode
Begin with a DMARC policy of p=none . This does not block mail. It asks receiving servers to send reports so you can see who is sending mail for the domain.
A basic record may look like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comThose reports are useful, but they can be difficult to read in raw form. Many organisations use a reporting tool to group senders, identify failures, and separate legitimate services from abuse.
5. Move gradually to quarantine, then reject
Once legitimate senders pass SPF or DKIM with alignment, increase protection.
A typical path is:
p=none to monitor
p=quarantine to send failing mail to spam
p=reject to block failing mail
Use percentage-based rollout if needed. For example, apply quarantine to a small share first, review the impact, then increase.
The final target for a mature domain is usually p=reject , but only after valid senders are accounted for.
Treat email authentication as a security baseline
Email authentication needs ownership. Marketing operations may manage campaign tools, IT may manage DNS and mail platforms, and security may manage fraud risk. If no one owns the full picture, gaps appear.
A strong baseline should include:
A maintained list of approved sending platforms.
SPF records reviewed after vendor changes.
DKIM enabled for every sender that supports it.
DMARC reporting monitored regularly.
A clear path from monitoring to enforcement.
Separate subdomains for higher-risk or high-volume sending.
This also helps incident response. If a customer reports a suspicious message, teams can check whether it passed authentication, identify the sending source, and act faster.
Google and Yahoo’s 2024 rules raised the cost of weak configuration. Business email compromise raised the cost of inaction long before that. The organisations that handle this well treat SPF, DKIM, and DMARC as basic controls, like multi-factor login or endpoint protection.
If you’re not sure your domain is protected against spoofing, it’s one of the first things we check when building a Security Baseline.
Email remains one of the most used business systems and one of the most abused. Proving that your messages are authentic is now a minimum standard for trust, delivery, and fraud prevention.
