Email Domain Reputation through Security
How to secure your email domain to ensure reputation and deliverability
Ever wondered why your emails end up in spam even when everything looks right?
Your email reputation determines whether your messages reach inboxes or vanish into the void of spam folders. Worse yet, a poor reputation can make your domain a prime target for impersonation and an attack vector against your customers and business partner.
Most emails sent daily are classified as spam or malicious, and email providers are fighting back hard. If your emails aren’t properly authenticated, they might never reach the inbox at all.
That’s where email reputation comes in. Your domain’s reputation dictates whether your messages land in inboxes, get flagged as suspicious, or vanish into the void and the key to a strong reputation are SPF, DKIM, DMARC, BIMI, STARTTLS, and more.
This guide breaks down exactly how these protocols work, how to configure them correctly, and which settings you should use for maximum deliverability and security.
We’re skipping the fluff this is a hands-on, technical deep dive designed to help you take control of your email infrastructure. By the end, you’ll have a rock-solid email reputation, improved deliverability, and stronger protection against spoofing and phishing attacks.
We’ll explore how to achieve email domain reputation through security measures and DNS Records
The Foundations of Email Domain Reputation Security: SPF, DKIM, DMARC
Email authentication is the backbone of email security. Without it, attackers can forge emails from your domain, tricking recipients into believing malicious emails are legitimate. Implementing SPF, DKIM, and DMARC not only protects your domain but also ensures your emails reach inboxes instead of spam folders.
These three protocols work together to prevent spoofing, phishing, and unauthorized email use, making them essential for any business or organization that relies on email communication.
At their core, these records act as digital gatekeepers as SPF determines which servers are allowed to send email for your domain, DKIM ensures messages haven’t been altered in transit and DMARC ties them together, providing policy enforcement and reporting.
Remember to not simply create the strictest security policy right away – it’s important to perform extensive tests and find the right balance between your business email deliverability needs and your security needs.
Let’s dive in to each of these records:
SPF - Sender Policy Framework
SPF helps prevent spammers from sending emails on your behalf. It works by specifying which mail servers are allowed to send emails for your domain.
The receiving server checks if the sending server’s IP is listed in your SPF record. If not, the email might be rejected (based on DMARC policy and ESG policy).
Important SPF Record Settings
- -all (hard fail) – Reject unauthorized emails.
- ~all (soft fail) – Mark unauthorized emails but still allow delivery.
- +all – Allows anyone to send email from your domain.
Example
v=spf1 mx a ip4: X.X.X.X/32 ip4:X.X.X.X/28 a:ns1.example.com include:emailsender.com ~all
- “v=spf1” – Defines the SPF version (SPF version 1).
- “mx” – Allows mail servers (MX records) listed for the domain to send emails.
- “a” – Permits the domain’s current IP address (A record) to send emails.
- “ip4:X.X.X.X/32 and ip4:X.X.X.X/28” – Specifies two allowed IP addresses or subnets.
- “a:ns1.example.com” – Authorizes the server ns1.example.com to send emails for this domain.
- “include:emailsender.com” – Includes SPF settings from emailsender.com, meaning that emailsender.com has an SPF record that allows it to send emails on behalf of example.com.
- “~all” – A “soft fail” policy, meaning emails from unauthorized sources should be accepted but marked as suspicious (more setting options mentioned above).
DKIM - DomainKeys Identified Mail
DKIM adds a cryptographic signature to your emails, proving they were sent by an authorized sender and weren’t tampered with in transit.
The recipient’s server verifies the DKIM signature against a public key in your DNS.
DKIM Record Settings
- s= (selector) – Defines the DKIM key identifier.
- p= (public key) – The cryptographic key used for verification.
- h= (headers signed) – Defines which headers are signed for validation.
Example
v=DKIM1; k=rsa;p=MIGfMA0GCSqyy1g+JaBXI1/sL8xmtdFxUJe3R/VTYS/PnglVsh2ac/S/U|dTsE+XDIJzeku…
- “v=DKIM1” – Defines the DKIM version (DKIM version 1).
- “k” – Defines the key algorithm used (RSA).
- “p” – The cryptographic key itself.
DMARC - Domain-based Message Authentication, Reporting & Conformance
DMARC builds on SPF and DKIM, allowing you (the sender) to define how recipient servers should handle authentication failures. It is important to mention that recipients can choose to ignore your DMARC policy once the email reaches their server.
When an email fails SPF or DKIM, the recipient follows your DMARC policy.
DMARC Record Settings
- p=X – Defines that action to take if SPF and DKIM checks fail and can be set to “none”, “quarantine” or “reject”.
- rua=[email address] – Defines where to send aggregate reports.
- ruf=[email address] – Defines where to send forensic failure reports.
- fo=X – Can be set to:
0 → Generate reports if both SPF and DKIM fail.
1 → Generate reports if either SPF or DKIM fails.
d → DKIM fails, regardless of alignment.
s → SPF fails, regardless of alignment.
- adkim=X – DKIM alignment mode can be set to “strict” or “relaxed”.
- aspf=X – SPF alignment mode can be set to “strict” or “relaxed”.
- pct=X – The percentage of emails subject to DMARC policy can be set between 0 to 100.
- sp=X – The subdomain policy defines that action to take if SPF and DKIM checks fail (for the subdomain) and can be set to “none”, “quarantine” or “reject”.
Example
v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=r; pct=100; sp=reject
- “v=DMARC1” – Defines the DMARC version (DMARC version 1).
- p=quarantine – The main DMARC policy set to quarantine emails that fail the checks.
- rua=mailto:[email protected] – The email address where aggregated (rua) DMARC reports should be sent.
- ruf=mailto:[email protected] – The email address where forensic (ruf) DMARC failure reports should be sent.
- fo=1 – Failure reporting options set to 1.
- adkim=s – DKIM alignment mode set to strict.
- adkim=r – DKIM alignment mode set to relaxed.
- pct=100 – The percentage of emails subject to DMARC policy set to 100%
- sp=reject – The subdomain DMARC policy set to reject emails that fail the checks.
How SPF, DKIM, and DMARC Work Together
No single email authentication method is enough on its own. SPF, DKIM, and DMARC must be used together to provide full protection.
Think of them as layers of defense, each addressing different aspects of email security where SPF ensures only authorized mail servers can send emails on your behalf (without it, anyone could spoof your domain and send fraudulent emails pretending to be from you) and DKIM verifies that an email hasn’t been altered in transit so that even if an attacker intercepts an email and change it, DKIM signature will not match and you will be able to know that the email has been tampered with.
DMARC enforces policies based on SPF and DKIM results and provides visibility into authentication failures, allowing you to monitor, quarantine, or reject suspicious emails.
By implementing all three together, you create a strong email security framework.
BIMI - Brand Indicators for Message Identification
Another important record is BIMI (Brand Indicators for Message Identification) that helps recipients visually verify email authenticity by displaying your brand’s logo next to authenticated messages.
BIMI works alongside DMARC so that if your email passes DMARC authentication (and in some cases must also pass VMC checks), a pre-approved logo appears next to your email in supported inboxes.
This really help to build trust and brand recognition, making is easier for a user to spot phishing attempts.
Today most major email providers support BIMI, adding an extra layer of credibility to your communications.
BIMI Record Settings
- default._bimi.[yourdomain] – The DNS name for the BIMI record.
- l=https://[yourdomain]/ [yourlogo].svg – Path to your logo.
- a=https://[yourdomain]/[yourvmc].pem – Path to your Verified Mark Certificate (VMC).
Example
default._bimi.example.com IN TXT “v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem;”
- default._bimi.example.com IN TXT – Domain set to example.com
- v=BIMI1 – Defines the BIMI version (BIMI version 1).
- l=https://example.com/logo.svg – Logo path in example.com and image logo.svg
- a=https://example.com/vmc.pem – VMC path in example.com and certificate vmc.pem
STARTTLS - Encrypting Email in Transit
STARTTLS upgrades plain-text email connections to encrypted ones, preventing attackers from intercepting sensitive information in transit.
When an email is sent, STARTTLS will establish a secure TLS encrypted connection between mail servers and if both servers support it, the email remains encrypted during transmission (just like any other TLS traffic).
Without STARTTLS, emails can be intercepted and read in plain text, exposing sensitive data which is why implementing STARTTLS ensures emails are protected while moving across the internet.
Common Email Based Threats & How to Prevent Them
When we think about Email based threats the first thing that comes to mind is of course “Phishing” and the solution is usually user awareness training or Email Security Gateway (ESG) and while phishing is a very serious and common threat there are many other email-based threats and many of them can be prevented by implementing the steps in this guide.
Let’s take a look at some of them:
Spoofing – Attackers forge domain to send fake emails
Spoofing attacks deceive recipients by making malicious emails appear as if they come from a trusted sender. These emails often contain phishing links or malware attachments, targeting both individuals and businesses.
Potential Solution: Implement SPF, DKIM, and DMARC with p=reject. Regularly monitor DMARC reports to detect spoofing attempts. Additionally, enable BIMI to visually confirm email authenticity for recipients.
Backscattering – Attackers send emails using your domain and flood non-delivery reports
Backscatter happens when your domain is forged in spam campaigns, leading to a flood of undeliverable bounce messages. Your inbox becomes overwhelmed with automated replies to emails you never sent.
Potential Solution: Use a strict DMARC policy, set your email server to reject messages from unauthorized senders, and configure bounce message handling to prevent unnecessary responses. Additionally, monitor your mail logs for sudden spikes in non-delivery reports.
Impersonation – Attackers pose as executives, vendors or employees
Impersonation attacks, such as CEO fraud, exploit social engineering to manipulate recipients into transferring funds or revealing sensitive information.
Potential Solution: Set strict SPF, DKIM, and DMARC settings and policy and enable BIMI to visually confirm email authenticity for recipients.
Wrap Up
Email reputation isn’t just about keeping your messages out of spam – it’s about security, trust, and protecting your brand, customers and partners.
Start with SPF, DKIM, and DMARC to protect your email reputation and use STARTTLS when possible. If you have the resources and need, get VMC and implement BIMI.
Most importantly, keep monitoring your reputation using tools like Google Postmaster Tools, MX Toolbox, Cloudflare and more.
Please note that the content provided here is a general guideline. Required actions can vary significantly depending on specific cases.
