What Is Email Security? Best Practices for 2025

Email security refers to various cybersecurity measures to secure the access and content of an email account or service.

Proper email security can protect sensitive information in email communications, prevent phishing attacks, spear phishing and email spoofing and protect against unauthorized access, loss or compromise of one or more email addresses.

Why is Email Security Important? 

Email security is important because malicious email is a popular medium for spreading ransomware, spyware, worms, different types of malware, social engineering attacks like phishing or spear phishing emails and other cyber threats.

Email is also a common attack vector for attackers looking to gain entry into an enterprise network to steal sensitive data like personally identifiable information (PII), protected health information (PHI) or intellectual property (industrial espionage). 

This can help with compliance with regulations such as GDPR, LGPD, the SHIELD Act, CCPA, CPS 234 by preventing data breaches. 

Secure email is necessary for both individual and business email accounts, and there are multiple measures organizations should take to enhance email security that we outline below. 

What is the Foundation of Email Security?

Email consists of three components:

1. The envelope: Concerned with how the email is routed, e.g. the path it takes to get to your inbox
2. The header(s): Contains information about the sender, recipient and various authentication details. 
3. The body of the message: The contents of the message, e.g. what you read and reply to. 

The authentication methods (SPF, DKIM and DMARC) allow the prevention of email spoofing (people pretending to be your domain) and the verification of the sender, largely rely on DNS records and adding or verifying the information provided in the:

• From header: This is the identity of the email author, typically what your email client shows to you when you receive an email. Ultimately, you want to have confidence the domain shown is actually who sent the email. This is only possible when you use all of the authentication methods outlined later in this article.
• Return-Path header: The identity of the sending email service: This value is taken from the MAIL FROM command sent at the beginning of a Simple Mail Transfer Protocol (SMTP) transaction by the machine sending the email. Mail servers and other message transfer agents use SMTP to send and receive email messages. Proprietary systems such as Microsoft Exchange and IBM Notes and webmail systems such as Outlook.com, Gmail and Yahoo! Mail may use non-standard protocols internally, but all use SMTP when sending to or receiving email from outside their own systems. The domain in the header does not need to be the same as the From domain and will often be different, e.g. if the email is forwarded through a mailing list before reaching its destination.  

What is Sender Policy Framework (SPF)?

Sender Policy Framework (SPF) is an email authentication method designed to detect forging of the sender address (Return-Path header) during the delivery of an email. 

SPF allows the receiving mail server to check during mail delivery that an email claiming to come from a specific domain was sent by an IP address authorized by that domain's owner. 

How to Implement SPF

To implement SPF, you need to add a DNS TXT recorded that lists all the IP addresses authorized to send email on behalf of your domain. 

Each domain can have a maximum of one SPF record, defined as a TXT or SPF record type.

You can generate an SPF record by using SPF Wizard. 

What is the Format of an SPF Record?

SPF records are defined as a simple piece of text. Here's UpGuard's record as an example:

v=spf1 include:_spf.google.com include:mail.zendesk.com include:228391.spf01.hubspotemail.net ~all

SPF records always start with the v= element. This indicates the SPF version that is used. At the time of writing, this should always be spf1 as this is the most common version of SPF that is understood by mail exchanges. 

One or more terms will follow the version indicator. These define the rules for which hosts are allowed to send mail from the domain, or provide additional information for processing the SPF record. Terms are made up of mechanisms and modifiers.

How Do SPF Mechanisms Work?

The following mechanisms define what IP addresses are allowed to send email from the domain:

• a
• mx
• ip4
• ip6
• exists

A mail server will compare the IP address of the sender against the IP addresses defined in the mechanisms. If the IP address matches one of the mechanisms in the SPF record, it will follow the resulting handling rule. The default handling rule is neutral.

The include mechanism allows you to authorize hosts outside of your administrations by specifying their SPF records. 

The all mechanism matches any address and is usually listed as the last mechanism to define how to handle any sender IP that is not included in the pervious mechanisms. 

All mechanisms can specify qualifiers for how to handle a match:

• +: pass
• -: fail
• ~: soft fail
• ?: neutral

So applying this to UpGuard's SPF record we can see that UpGuard is using version spf1, allows _spf.google.com, mail.zendesk.com and 228391.spf01.hubspotemail.net to send email on our behalf, and for any other situations it soft fails.  

How Do SPF Modifiers Work?

Modifiers are name/value pairs, separated by an = sign, that provide additional information. 

The redirect modifier is used when you have multiple domains and want to apply the same SPF content across them. Redirects should only be used when you control both domains, otherwise an include is used. 

The exp modifier is used to provide an explanation in the case of a - (fail) qualifier.

What are the SPF Check Outcomes?

These are the possible outcomes of an SPF check, see RFC 7208 section 8 for more detail:

• None: No SPF record exists.
• Neutral: SPF record was found with no positive or negative assertion was made about the sender, the result is equivalent to None.
• Pass: The sender is authorized to send mail on behalf of the domain.
• Fail: The sender is not authorized and the mail server may choose to reject the email.
• Soft fail: The sender is not authorized but the mail server should not reject the mail based solely on this result. 

Why is SPF Not Enough to Authenticate an Email? 

SPF alone can only authenticate the source of the message (Return-Path) but not the original author. 

There is nothing stopping an attacker from setting up their own mailbox and domain, with an SPF record that authorizes the attacker's IP address to send email on behalf of that domain. 

Any email sent would pass SPF checks and they could still spoof the From header which is out of the scope of SPF. 

Only in combination with DMARC and DKIM can SPF be used to prevent email spoofing, a technique often used in phishing and spear phishing campaigns. 

What is DomainKeys Identified Mail (DKIM)?

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails. 

DKIM allows the receiver to check that an email claimed to have come from a specific domain was authorized by the owner of that domain.

This is achieved by affixing a digital signature, linked to a domain name to each outgoing email message. 

The recipient system can then verify the email by looking up the sender's public key, which is published in the DNS.

A valid signature also guarantees that some parts of the email (such as email attachments) have not been modified since the signature was affixed. DKIM signatures are not generally visible to end-users and are affixed or verified by infrastructure rather than the message's author and recipients.

How to Implement DKIM 

Like SPF, implementing DKIM requires you to update your DNS. It is a little more involved than SPF, as you need to:

• Choose a DKIM selector: A selector can be anything you want, such as a word, number, or a string of letters and numbers. Specified as an attribute for a DKIM signature and is recorded in the DKIM-Signature header field. As DKIM selectors give different DNS query names, the system uses the selectors as an additional name component for validation. Selectors enable multiple DKIM keys under a domain name, which can provide different controls among departments, date ranges or third-parties acting on behalf of your domain. No two services or products should use the same selector. 
• Generate a public-private key pair:You can generate a DKIM record here.
• Publish the selector and public key: As TXT record or CNAME pointing to your provider's DNS.
• Attach the token to each outgoing email

That said, DKIM records are often provided to you by the organization that is sending your email, for example SendGrid, Postmark or Google Apps. 

What is the Format of a DKIM Record?

DKIM records are defined as a piece of text. Here's UpGuard's DKIM record for selector s=google and the associated public key as an example:

How Does DKIM Work?

DKIM works by affixing a signature to the email as a header, for example:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

        d=upguard.com; s=google;

        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;

        bh=ewH2APsHZpkiGwY6K2zF2Es1X6R5cM87=;b=QoetI61NcfEB9ukMtPM8GPC26HcMWHK

The signature includes the domain responsible for creating the signature, upguard.com (d=upguard.com) in this case as well as the selector, google (s=google).

The signature was created by using the private key associated with the DKIM record and public key shown above and is only known by the domain owner. 

Anyone could validate that this signature was created by UpGuard's google selector DKIM private key by using the public key stored in our DNS TXT record. 

What is the Benefit of DKIM? 

When a valid DKIM signature is affixed to an email, the receiver can be confident that the DKIM signature has been created by the owner of that domain.  

Why is DKIM Not Enough to Authenticate an Email?

A valid DKIM signature only verifies that the DKIM signature was created by the owner of that domain. It does not necessarily mean that the From domain is the same. 

An attacker could easily create a valid DKIM signature for a domain she controls while still spoofing the From domain. 

Thus, like SPF, DKIM alone is not always enough to authenticate the domain in the From header.

What is Domain-Based Message Authentication, Reporting and Conformance (DMARC)?

DMARC is an email authentication protocol designed to give email domain owners the ability to protect their domain from unauthorized use, e.g. email spoofing.

The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise (BEC) attacks, phishing emails, email scams and other email threats. 

DMARC provides a mechanism to:

• Authenticate the domain in the From header of an email, based on the results of SPF and DKIM
• Allow domain owners to set a policy for handling email based on the result of that authentication
• Allow domain owners to get feedback reports from mail receivers on the results of DMARC checks

Read more about DMARC here.

How to Implement DMARC

Like SPF and DKIM, implementing DMARC requires you to update your DNS. 

Once the DMARC DNS entry is published, any receiving email server can authenticate the incoming email based on the instructions published by the domain owner within the DNS entry. If the email passes the authentication, it is delivered and can be trusted.

If the email check fails, the p element of the DMARC record is the most important part of the DMARC record as it tells the receiving email server what to do, namely:

• None: The domain owner requests no specific action be taken regarding delivery of the messages. This is effectively the same as having no DMARC record at all. Any existing mail filtering policies should not be impacted, e.g. SPF. This is generally used by domain owners who want to start collecting feedback reports to determine what impact DMARC will have once a stricter policy is enforced.
• Quarantine: The domain owner wishes for email receivers to have emails that fail the DMARC check to be treated as suspicious. This typically means the email will end up in spam. 
• Reject: The domain owner wishes for email receivers that fail the DMARC check to reject the email. 

You can generate a DMARC record here.

What is the Format of a DMARC Record?

The DMARC policy, like SPF and DKIM, is stored in a DNS TXT record under the _dmarc subdomain of the From domain e.g. _dmarc.upguard.com. 

This means the policy will be applied any time an email is received with upguard.com as the From domain. 

The policy will also apply to email received from a subdomain of upguard.com, unless the subdomain defines its own policy. This is an improvement over how SPF policy discovery works, where there is no mechanism to set a single policy for all subdomains. 

How Does a DMARC Check Work?

The process of performing a DMARC check is to:

• Extract any SPF check that produces a Pass result
• Extract any valid DKIM signatures found in the email
• Compare the domain used to perform the SPF check (Return-Path) and the DKIM domain (per the DKIM signature) with the From domain
• If the domain does not match the From domain, the result is discarded
• By default, the organizational or root domains are compared
• If we are left with either a valid DKIM signature or an SPF check with a Pass result, and the From domain matches, then the DMARC check is satisfied

Is DMARC Enough to Authenticate an Email?

Yes. DMARC allows you to authenticate an email because DMARC aligns the domain from the SPF and DKIM results from the From domain and gives you confidence about the identity of the author. 

What Happens When There is a Conflict between SPF and DMARC Policies?

SPF and DMARC both provide a mechanism to decide when email should be rejected and they may not always agree. 

For example, the SPF check may product a Fail, which directs the receiver to reject the email. But if there is a valid DKIM signature for the From domain, that would satisfy the DMARC check. Recall, it checks for either a valid DKIM signature or an SPF Pass result.

In this situation, it depends on local email protection policies. 

Section 6.7 of RFC 7489 states: 

An operator that wishes to favor DMARC policy over SPF policy, for example, will disregard the SPF policy, since enacting an SPF-determined rejection prevents evaluation of DKIM; DKIM might otherwise pass, satisfying the DMARC evaluation.  There is a trade-off to doing so, namely acceptance and processing of the entire message body in exchange for the enhanced protection DMARC provides.

DMARC-compliant Mail Receivers typically disregard any mail-handling directive discovered as part of an authentication mechanism (e.g., Author Domain Signing Practices (ADSP), SPF) where a DMARC record is also discovered that specifies a policy other than "none".  Deviating from this practice introduces inconsistency among DMARC operators in terms of handling of the message.  However, such deviation is not proscribed.

To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" SHOULD NOT modify existing mail disposition processing.

Further, section 10.01 warns using a hard fail on an SPF record (e.g. -all) may cause email to be rejected by some mail receivers before DMARC processing happens.

SPF, DKIM and DMARC Recommendations

We recommend all organizations deploy an effective (p=quarantine or p=reject) DMARC policy on all domains with supporting DKIM and SPF implementations. The policy should apply to all subdomains, i.e. sp=none )(this is an optional tag to explicitly set the policy for subdomains) should not be used. This will protect cyber criminals pretending to be your organization in outbound emails. Additionally, obeying DMARC policies will protect against inbound emails. 

If your organization does not delegate control of subdomains to untrusted parties, then the default relaxed alignment mode can be used to compare SPF and DKIM domains.

Additionally, the pct tag should not be set to less than 100, i.e. your DMARC policy should apply to all emails.

The good news is there are many SaaS products designed to help you migrate to an effective DMARC policy. They also help you identify configuration issues by aggregating, parsing and analyzing reports from mail receivers.

Finally, your SPF policy should not be overly permissive. e.g. a Pass catch-all (+all) should not be used, nor should the ptr mechanism, see RFC 4408 section 5.5.

If a DMARC policy is not deployed or is set to p=none use a Fail catch-all (-all) and publish an SPF record for all domains and subdomains even if they are not used for legitimate email. 

However, if you have followed our recommendations above, i.e. you have a DMARC policy deployed with p=quarantine or p=reject you can use a Soft fail catch-all (~all). 

This helps avoid the situation where mail receivers reject mail based on the SPF result before checking DMARC (see Section 10.1 of RFC 7489). 

A Soft fail is fine because a Pass SPF result is required to pass DMARC and therefore the difference between a Fail and Soft fail is not important. 

The benefit of this approach is that you only need to publish SPF records on subdomains which are used by the organization to send legitimate email, provided the parent domain applies a DMARC policy and mail receivers check it.

This is because subdomains without SPF records would not produce the Pass result required to pass DMARC checks and thus would not be exposed to email spoofing.

Don't Forget About DNSSEC

DNSSEC provides a way to protect against DNS spoofing and is an often overlooked part of email security. DNS spoofing is a type of cyber attack where an attacker reroutes a valid DNS address to the IP of a malicious server. 

As SPF, DKIM and DMARC all rely on DNS TXT records, DNS spoofing undermines the security they provide. 

Additional Email Security Controls

There are a variety of additional email security solutions you can employ to improve your email security beyond SPF, DKIM, DMARC and DNSSEC such as:

• Email encryption: Encrypting or disguising the contents of email messages or email attachments to protect potentially sensitive information from being read by anyone other than the intended recipients. This can also help with data loss prevention (DLP).
• An antivirus: Antivirus software often has real-timeadvanced threat protection that can detect known virus and malware signatures
• A secure email gateway (SEG): A cloud-hosted or on-premise device or software used to monitor emails that are sent and received.
• Anti-spam: Refers to any software, hardware or processes that are used to combat the proliferation of spam or keep spam from entering a system. For example, opt-in email is a common anti-spam process. 
• Strong passwords: Require employees to use strong passwords and mandate password changes periodically. See our secure checklist password for more information.
• Cybersecurity awareness training: Security teams must invest in training their staff as many cyber attacks are spread through malicious email attachments. Sandboxing email attachments such as Microsoft Office or Office 365 files can help too.

Read our email security checklist for more controls. 

Email Security FAQs

What is Email Security?

Email security refers to a system of solutions designed to keep email accounts safe from compromise.

What are the different types of email Security?

‍

Strategies for increasing email security include:

• Implementing a Sender Policy Framework (SPF).
• Implementing DKIM
• Using an anti-virus solution
• Enforcing email encryption policies

What are the security risks associated with using emails?

The primary security risk is phishing attacks. During a phishing attack, cybercriminals send fraudeulemt emails infected with malicious links or attachments. When a target interacts with a phishing email, they either enter a funnel designed to steal sensitive credentials or initiate the installation of malware.  

What are good email security practices?

Best email practices include:

• Never interacting with suspicious emails
• Instantly reporting suspicious emails to security teams
• Always confirm the legitimacy of emails from colleagues by contacting them directly (either by composing a new email or through dedicated internal company communication channels).