These email security protocols will help cut down on malicious emails from spoofed addresses. Setting them up is easier than you think. Credit: MicroStockHub / Getty Images If you are not using global email security standards SPF, DKIM and DMARC, you should be. They’ve been around for many years and used and trusted by millions of people. They can only help.Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM) and Domain-Based Message Authentication, Reporting and Conformance (DMARC) allow you to prevent malicious third parties from spoofing your email domain to others who use it. They don’t work perfectly, but when enabled will absolutely cut down on some forms of email maliciousness.For these protocols to work, the sender’s email domain administrator enables them in DNS using TXT records. (TXT records are a particular type of DNS record, like an A record is), or by enabling it in their email host provider’s administrative console. When enabled, receivers (actually their email servers or clients on their behalf) of emails from activated domains can check additional information to verify whether a particular email came from the email domain from which it claims to be sent.It’s a little confusing. Sending domains enable the protocols so that receivers can verify that emails are really from the sender’s domain. Senders enable these protocols so other people can’t claim to be them. Receivers enable them so they can verify whether a particular email is from where it says it’s from. Both sides must be enabled. Enabling them can’t hurt anything, unless you decide to take the draconian step of rejecting all emails that fail any of the checks. Hint: This will cause far too many false positives, so choose to quarantine instead. SPF works by preventing spoofing of a legitimate email real return address (i.e., the email address that you would be sending a reply to) domain. This email address is known as the 5321 address, because it is defined in RFC 5321, which defines Simple Mail Transfer Protocol (SMTP). Depending on the email client, the 5321 address may not always be displayed. This is especially true of small form-factor email clients such as the ones you see on smartphones.DKIM works by preventing the spoofing of the “Display From” email address (from RFC 5322, Internet Message Form email standard) domain. The Display From address is almost always shown to an end-user when they preview or open an email, hence its name. The figure below shows the difference between the 5321 and 5322 email addresses. Roger GrimesThe difference between the 5321 and 5322 email addressesAlthough these addresses can differ in legitimate email, they are more likely to differ in malicious emails. I’ve always considered it to be much like the difference between what a URL link looks like in an email and what it really is when hovering a mouse cursor above it. Whenever I see two different things, I get a little wary. In most emails, the two URL versions should agree, and hovering over one should just verify that it matches the more obvious display name (which can be spoofed).SPF and DKIM allow receivers of emails to ensure that the domains (and domains only) of a received email are really from the email servers of those claimed domains. However, they do it quite differently. DMARC is an additional standard that essentially tells others relying on your SPF and DKIM records how they should treat failing or spoofed emails.Note: SPF and DKIM only verify the legitimacy of the sending and claimed domains (e.g., @example.com). The email address name portion before the email domain (e.g., roger@ or rogerg@) could still be spoofed by a malicious sender.How to use SPFSenders enable SPF for their domain by creating at least one DNS TXT record. When creating the SPF DNS TXT record, you need to have a few pieces of information handy, including which email server(s) do you want handling each defined domain and their public IP addresses.Useful SPF configuration links include Rackspace’s instructions on creating an SPF TXT record; Proofpoint’s SPF Check, which lets you find out which servers are authorized to send email on behalf of a domain; and SPF Wizard, which helps you craft the necessary DNS record based on your query answers.If still in doubt, contact your ISP or email domain provider. They should be able to tell you what you need to include in the DNS TXT record. Here’s some simple SPF example TXT records: com. IN TXT "v=spf1 -all"com. IN TXT “v=spf1 a ip4:192.168.1.1 ~all”Microsoft Office 365 users should refer to the Microsoft knowledgebase to enable SPF for their domain.Here’s what a verified SPF email header looks like once it gets to an email client: Roger GrimesVerified SPF email headerHere’s what a verified failed SPF header looks like once it gets to an email client: Roger GrimesVerified failed SPF headerRemember, with all these technologies, the end-user is not usually examining headers or determining whether to look at a particular email. This is all done in the background by the receiving email server/service, although understanding what the headers look like in pass and fail modes can help those of us who care enough to examine the headers when we see a suspicious email.How to use DKIMDKIM takes a bit more knowledge than SPF to set up. It requires a modification to that sender’s email server/servicei. The sender has to create/get a cryptographic public/private key pair, install it on their email server/service, and then create a DNS TXT record that contains their public key. Each outgoing email is signed by the email server’s private key and receivers can verify the digitally signed email by using the sender’s public key.Here’s an example of a DKIM DNS TXT record (p is the public key of email server in Base64 format):selector._domainkey.example.com IN TXT “v=DKIM1;p=RAG…123”This is an example DKIM email header: Roger GrimesDKIM email headerThis is an example of a DKIM email header successfully verified: Roger GrimesVerified DKIM email headerHow to use DMARCDMARC is simply an aggregator service to determine whether the sender uses SPF and DKIM, and how the sender recommends receivers should treat failed/spoofed emails claiming to be from the sender’s domain. Like SPF and DKIM, it is set up in DNS as a TXT record by the sender.A DMARC DNS TXT record might look similar to this:TXT IN "v=DMARC1;p=quarantine;pct=100;rua=mailto:dmarccheck@example.com;"One of the most important fields is the p value, which indicates how the sender wants receivers to treat failed emails. P can be one of three values:None – take no special treatment for failed emailsQuarantine – treat as suspiciousReject – reject email at server before it gets to clientBe aware that legitimate emails fail one or more SPF, DKIM and DMARC checks routinely. This is often because someone configured something wrong, the email is incorrectly manipulated, or other reasons. Anyone choosing the “reject” value will probably be killed by management or their end-users because they did not get legitimate emails. Be safe and go with “quarantine” instead. Even then, many email services will just act as if “none” was specified.Protocols are not perfectSPF, DKIM DMARC are not perfect, for many reasons including these:Hacker could be sending a malicious email from within a compromised domain environmentHacker could be using a domain that enables and uses SPF and DKIMMany commercial email hosts do not respect your settings or all settings. Many times, it’s due to the way large email hosts work using many servers over many changing IP addresses to send email on behalf of your domainEven with the flaws, enabling SPF, DKIM and DMARC can only help you. It will cut down on some portion of your fraudulently received spoof emails, and that is only good.Just be sure to never completely reject any email that fails one or more verification tests. Legitimate emails fail these checks all the time. You want to set SPF, DKIM and DMARC so that they will let any failed email be inspected by a human defender (i.e., quarantined). If you find that SPF, DKIM or DMARC causes too many problems, you can always choose less aggressive settings, or if a complete failure, disable them altogether (although I’ve not seen anyone who has had to do this yet).One more note. Office 365 users frequently complain that Microsoft does not respect all their email defense settings. Many 0ffice 365 admins set up an Exchange rule to block emails that spoof the receiver’s own domain. Related content news analysis Attackers breach US government agencies through ColdFusion flaw Both incidents targeted outdated and unpatched ColdFusion servers and exploited a known vulnerability. By Lucian Constantin Dec 06, 2023 5 mins Advanced Persistent Threats Cyberattacks Vulnerabilities news BSIMM 14 finds rapid growth in automated security technology Embrace of a "shift everywhere" philosophy is driving a demand for automated, event-driven software security testing. By John P. Mello Jr. Dec 06, 2023 4 mins Application Security Network Security news Almost 50% of organizations plan to reduce cybersecurity headcounts: Survey While organizations are realizing the need for knowledgeable teams to address unknown threats, they are also looking to reduce their security headcount and infrastructure spending. By Gagandeep Kaur Dec 06, 2023 4 mins IT Jobs Security Practices feature 20 years of Patch Tuesday: it’s time to look outside the Windows when fixing vulnerabilities After two decades of regular and indispensable updates, it’s clear that security teams need take a more holistic approach to applying fixes far beyond the Microsoft ecosystem. By Susan Bradley Dec 06, 2023 6 mins Patch Management Software Threat and Vulnerability Management Windows Security Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe