[Blog](/blog) Show links Resources [Blog](/blog) [Breaches](/breaches) [eBooks, reports, & more](/resources) [Events](/events) [News](/news) [Attack Surface Management](/category/attack-surface-management) Show links Categories [Attack Surface Management](/category/attack-surface-management) [Company News](/category/company-news) [Compliance and Regulations](/category/compliance-and-regulations) [Cybersecurity](/category/cybersecurity) [Data Breaches](/category/data-breaches) [DevOps](/category/devops) [Human Cyber Risk](/category/human-cyber-risk) [Risks and Vulnerabilities](/category/risks-and-vulnerabilities) [Third-Party Risk Management](/category/third-party-risk-management) [Vendor Risk Management](/category/vendor-risk-management) [What Is Email Security? Best Practices for 2026](/blog/email-security) Publish date January 5, 2026 {x} minute read # What Is Email Security? Best Practices for 2026 [Get a demo](/contact-sales) [Free trial](/demo) [Download the PDF guide](/resources/the-email-security-checklist) [Free trial](/demo) Written by [Abi Tyas Tunggal](/team/abi-tyas-tunggal) Writer and Senior Product Manager at UpGuard. Abi's work has influenced leaders across cybersecurity, technology, and financial services. Reviewed by [Kaushik Sen](/team/kaushik-sen) Chief Marketing Officer Kaushik has a background in software engineering, enterprise solution architecture, and data analytics. He brings a unique, data-driven perspective to cybersecurity education. Table of contents Checklist The Email Security Checklist Free resource ### The Email Security Checklist [Download now](/resources/the-email-security-checklist) Email security refers to various [cybersecurity](/blog/cyber-security) measures to secure the access and content of an email account or service. Proper email security can protect [sensitive information](https://www.upguard.com/blog/sensitive-data) in email communications, prevent [phishing attacks](https://www.upguard.com/blog/phishing), [spear phishing](https://www.upguard.com/blog/spear-phishing) and [email spoofing](https://www.upguard.com/blog/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](https://www.upguard.com/blog/ransomware), [spyware](https://www.upguard.com/blog/spyware), [worms](https://www.upguard.com/blog/computer-worm), [different types of malware](https://www.upguard.com/blog/types-of-malware), [social engineering attacks](https://www.upguard.com/blog/social-engineering) like [phishing](https://www.upguard.com/blog/phishing) or [spear phishing](https://www.upguard.com/blog/spear-phishing) emails and other [cyber threats](https://www.upguard.com/blog/cyber-threat). Email is also a [common attack vector](https://www.upguard.com/blog/attack-vector) for attackers looking to gain entry into an enterprise network to steal sensitive data like [personally identifiable information (PII)](https://www.upguard.com/blog/personally-identifiable-information-pii), [protected health information (PHI)](https://www.upguard.com/blog/protected-health-information-phi) or intellectual property ([industrial espionage](https://www.upguard.com/blog/corporate-espionage)).  This can help with compliance with regulations such as GDPR, [LGPD](https://www.upguard.com/blog/lgpd), [the SHIELD Act](https://www.upguard.com/blog/shield-act), [CCPA](https://www.upguard.com/blog/what-is-the-ccpa), [CPS 234](https://www.upguard.com/blog/apra-cps-234-information-security-prudential-standard) by [preventing data breaches](https://www.upguard.com/blog/prevent-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](https://www.getmailbird.com/what-is-an-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](https://www.spfwizard.net/).  ### 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](https://www.upguard.com/blog/dmarc) and DKIM can SPF be used to prevent [email spoofing](https://www.upguard.com/blog/email-spoofing), a technique often used in [phishing](https://www.upguard.com/blog/phishing) and [spear phishing campaigns](https://www.upguard.com/blog/spear-phishing).  ## 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](https://www.upguard.com/blog/third-party-vendor) 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](https://www.sparkpost.com/resources/tools/dkim-wizard/). * **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](https://www.upguard.com/blog/email-spoofing). The purpose and primary outcome of implementing DMARC is to protect a domain from being used in [business email compromise (BEC) attacks](https://www.upguard.com/blog/business-email-compromise), 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](/blog/dmarc). ### 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](https://powerdmarc.com/how-to-publish-a-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](https://dmarcian.com/dmarc-record-wizard/). ### 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](https://tools.ietf.org/html/rfc7489#section-6.7) 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](https://tools.ietf.org/html/rfc7489#section-10.1) 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. s*p=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](https://tools.ietf.org/html/rfc4408#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](https://tools.ietf.org/html/rfc7489#section-10.1)).  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](https://www.upguard.com/blog/email-spoofing). ## Don't Forget About DNSSEC [DNSSEC](https://www.upguard.com/blog/the-email-security-checklist) 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](https://www.upguard.com/blog/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)](/blog/data-loss-prevention). * **An antivirus: **Antivirus software often has real-timeadvanced threat protection that can detect known virus and [malware](https://www.upguard.com/blog/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](https://www.validity.com/blog/what-is-a-spam-trap/).  * **Strong passwords: **Require employees to use strong passwords and mandate password changes periodically. [See our secure checklist password for more information](https://www.upguard.com/blog/the-password-security-checklist). * **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](https://www.upguard.com/blog/the-email-security-checklist).  ### 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). Checklist The Email Security Checklist Free resource ### The Email Security Checklist [Download now](/resources/the-email-security-checklist) ## Related posts Learn more about the latest issues in cybersecurity. Attack Surface Management #### [Find Out if You're Exposed on the Dark Web](/blog/find-out-if-youre-exposed-on-the-dark-web) Answer 5 quick questions to predict what a dark web scan will find about your company. Then run the free scan to see your real exposure. [](/team/lance-turner) [Lance Turner](#) October 14, 2026 Data Breaches #### [Your First Dark Web Scan Report, Explained](/blog/your-first-dark-web-scan-report-explained) You scanned your domain. What do the results mean? [](/team/lance-turner) [Lance Turner](#) October 13, 2026 Cybersecurity #### [12 Cybersecurity Horror Stories of 2026 (No Costume Required)](/blog/cybersecurity-horror-stories-2026) A warning ignored once becomes a headline. Read more about these 12 real 2026 cybersecurity incidents, and the sign each one gave before it made the news. [](/team/revashni-moodley) [Revashni Moodley](#) October 14, 2026 Data Breaches #### [Good Security Rating? Your Dark Web Exposure Says Otherwise](/blog/good-security-rating-your-dark-web-exposure-says-otherwise) Scan your domain to see just how exposed you are on the Dark Web. [](/team/lance-turner) [Lance Turner](#) October 13, 2026 Cybersecurity #### [Left Unsupervised: 10 Times Access Outlived Its Authorization](/blog/10-times-access-outlived-authorization) Access granted once shouldn’t mean access forever. Read more on how unmonitored access caused 10 of these real-life breaches and what they taught us. [](/team/revashni-moodley) [Revashni Moodley](#) August 25, 2026 Cybersecurity #### [Surviving a LockBit Ransomware Attack: The ROI of Visibility](/blog/surviving-a-lockbit-ransomware-attack) Read how veteran CISO Nick Gicinto saved his alma mater from a LockBit ransomware attack by discarding the standard playbook. [](/team/nicholas-sollitto) [Nicholas Sollitto](#) June 1, 2026 [All posts](/blog) Experience superior visibility and a simpler approach to cyber risk management [Get a demo](/contact-sales) [Free trial](/demo)