If you are not using global email security standards SPF, DKIM and DMARC, you should be. They\u2019ve 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\u2019t work perfectly, but when enabled will absolutely cut down on some forms of email maliciousness.For these protocols to work, the sender\u2019s 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\u2019s 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\u00a0 came from the email domain from which it claims to be sent.It\u2019s a little confusing. Sending domains enable the protocols so that receivers can verify that emails are really from the sender\u2019s domain. Senders enable these protocols so other people can\u2019t claim to be them. Receivers enable them so they can verify whether a particular email is from where it says it\u2019s from. Both sides must be enabled. Enabling them can\u2019t 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 \u201cDisplay From\u201d 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\u2019ve 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\u2019s instructions on creating an SPF TXT record; \u00a0Proofpoint\u2019s 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\u2019s some simple SPF example TXT records:com. IN TXT "v=spf1 -all"com. IN TXT \u201cv=spf1 a ip4:192.168.1.1 ~all\u201dMicrosoft Office 365 users should refer to the Microsoft knowledgebase to enable SPF for their domain.Here\u2019s what a verified SPF email header looks like once it gets to an email client: Roger GrimesVerified SPF email headerHere\u2019s 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\u2019s 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\u2019s private key and receivers can verify the digitally signed email by using the sender\u2019s public key.Here\u2019s 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 \u201cv=DKIM1;p=RAG\u2026123\u201dThis 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\u2019s 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:firstname.lastname@example.org;"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 \u2013 take no special treatment for failed emailsQuarantine \u2013 treat as suspiciousReject \u2013 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 \u201creject\u201d value will probably be killed by management or their end-users because they did not get legitimate emails. Be safe and go with \u201cquarantine\u201d instead. Even then, many email services will just act as if \u201cnone\u201d 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\u2019s 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\u2019ve 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\u2019s own domain.