Category: Email

The European Accessibility Act (EAA): Are Your Emails Compliant?

The European Accessibility Act (EAA) is a new EU directive designed to make products and services, including digital communications, accessible to people with disabilities. Approved in 2019, the EAA will enter into force on June 28, 2025. After that date, businesses operating in the EU (or serving EU customers) must ensure that their digital content – websites, apps and emails – meet strict accessibility standards. In practice, this means that every marketing newsletter or transactional message you send to European users needs to be perceivable, operable, understandable and robust, in line with established guidelines.

Complying with the EAA is not just about avoiding fines – it’s about reaching a wider audience. An estimated 135 million people in the EU have disabilities. Accessible emails ensure your message gets to everyone (and isn’t filtered out by assistive technology). Conversely, ignoring email accessibility now puts your business at risk of legal penalties and market exclusion when the 2025 deadline arrives. This blog will explain the EAA’s requirements for emails, the risks of non-compliance, and how to make both marketing and transactional emails fully accessible. We’ll cover practical coding tips (headings, alt text, contrast, etc.), show examples of compliant vs. non-compliant email design, and point you to key standards like WCAG 2.1 AA and EN 301 549. Finally, we’ll give you an email accessibility checklist of best practices to help you get ready well before 2025.

Under the EAA, June 28, 2025 is the hard deadline. By that date, all new products and services must comply with EU accessibility rules. In practice, that means if your company is sending emails in 2026, those emails will have to meet EAA standards. (Older contracts have a transition grace period until 2030, but don’t count on that for your email campaigns.) Enforcement will be handled by national authorities in each member state, through market surveillance and penalties.

The consequences for failing to comply can be severe. While member states set their own fines, reports suggest penalties range from thousands to hundreds of thousands of euros per violation. For example, some EU regulators impose daily fines for ongoing issues (around €1,000/day in some cases), and repeated or serious breaches can trigger much larger fees. ReciteMe notes that some countries allow fines up to €250,000 for major accessibility failures. In addition to direct penalties, non-compliant businesses risk lawsuits (including consumer complaints) and damage to their reputation. Regulatory scrutiny could even bar you from certain EU markets, especially if you bid for public-sector contracts that increasingly require accessibility.

Bottom line: as of mid-2025, “business as usual” emails in the EU must be accessible. Ignoring this won’t just be a technical oversight – it could trigger fines, lost customers, and legal action. The good news is that you have time to prepare. Start by understanding the guidelines for accessible emails below, and begin auditing and updating your templates now.

Who Must Comply?

The EAA applies to companies that supply digital services to EU markets, which includes email marketing and customer communications. The rules do not apply to micro-enterprises (fewer than 10 employees and under €2 million turnover), but beyond that threshold, nearly all businesses with an EU presence are covered. In practice, if you send email newsletters or transactional emails (order confirmations, password resets, etc.) to EU recipients, you need to meet the EAA’s accessibility requirements. For instance, Mailgun confirms that both marketing emails and essential service emails (like receipts or shipping notices) “fall under the umbrella of digital services” and must comply.

Core Accessibility Standards: WCAG and EN 301 549

The EAA is a law, not a design guide, so it doesn’t spell out exact technical methods. Instead, it incorporates established standards. The key benchmark is WCAG 2.1 AA (Web Content Accessibility Guidelines, level AA), which defines success criteria for digital content. The EAA refers to EN 301 549 – the EU’s harmonized ICT accessibility standard – and EN 301 549 already incorporates WCAG 2.1 AA for web/digital content. In effect, following WCAG 2.1 AA is the way to achieve “EAA compliance” for emails. As one accessibility expert puts it, “to be EAA-compliant, businesses must adhere to WCAG 2.1 Level AA”.

So how do you make an email WCAG 2.1 AA–accessible? At a high level, WCAG covers things like text alternatives, contrast, keyboard operability, semantic structure, and more (the four POUR principles). Much of WCAG for websites can be applied to HTML email: e.g. provide alt text for images, ensure sufficient contrast (ratio 4.5:1 or higher for normal text), use proper headings and labels, make sure interactive elements are keyboard-accessible, and so on. (Note: some interactive features like complex scripts or ARIA roles may be limited by email client support, but you should follow best practices wherever possible.) In this blog we’ll go through the main points.

Technical Best Practices for Accessible Emails

Below are key guidelines and implementation tips for making emails accessible. These apply to both marketing campaigns and transactional emails (order confirmations, notifications, etc.). Whenever possible, use HTML format (rather than plain text or RTF) so you can include semantic markup.

  • Use semantic structure (headings, paragraphs, lists). Organize your email like a well-written article: a clear main heading, logical subheadings, and content in logical order. For example, use an <h1> tag for the email’s main title, and use <h2>, <h3>, etc. for subsections. Screen reader users often navigate by jumping between headings, so this structure matters. Never rely on images for text headlines; use real text and heading tags. Also wrap text in <p> (paragraph) tags rather than using manual <br> line breaks, so that assistive technologies know where paragraphs begin and end. Bullet-point lists should use <ul>/<li> or <ol> tags for proper list structure.
  • Provide meaningful alternative text for images. Every informative image must include a concise but descriptive alt attribute. The alt text should convey the image’s purpose or content (“red leather handbag with gold hardware” rather than “image of product”). Decorative images (purely visual flourishes) should use alt="" so screen readers skip them. Never use an image of text to convey important information; if you do, include that text in the surrounding HTML as well. (In other words, don’t put sale prices or instructions only in an image – always have the same info as selectable text.) Including alt text is critical: without it, a screen reader will either skip the image or announce an unhelpful filename, and the user misses the content.
  • Ensure high color contrast and readability. Text must be easy to read against its background. WCAG 2.1 requires a contrast ratio of at least 4.5:1 for normal text (3:1 for large text). Concretely, black text on white is ideal; avoid light gray text on white or any low-contrast combination. You can test colors with tools like the WebAIM Contrast Checker. Use sufficiently large font sizes (generally >= 14px) and readable font families (sans-serif fonts like Arial or Verdana). Left-align body text for better readability, and use ample line spacing (1.5×) if possible. Avoid conveying meaning by color alone (e.g. “green means success”); always use text or symbols in addition to color cues.
  • Write clear, descriptive link and button text. Every link or button in the email should have context. Avoid vague phrases like “Click here” or “Submit”. Instead, use specific text such as “Download your invoice” or “View Order Details” that tells the user where the link goes or what it does. Screen reader users often navigate by jumping from one link to the next, so each link must make sense out of context. As Section508 guidance puts it: “Avoid generic terms and phrases such as ‘Click here.’ Create link text that’s as specific as possible”.
  • Design for keyboard navigation. Some recipients will use the keyboard rather than a mouse. Ensure all interactive elements (links, buttons) are reachable by tabbing. Focus indicators (outline or underline) should be visible so users know which element is active. Most email clients handle basic tabbing by default, but test it. For example, tab through your email using only the keyboard: does the focus move in a logical order (left-to-right, top-to-bottom)? If you’ve added custom CSS, make sure it hasn’t removed the browser’s native focus styles.
  • Be mindful of email client quirks. Not all email clients support every feature of HTML/CSS. For instance, older Outlook for Windows uses the Word rendering engine, which can drop many CSS rules. To handle this, many experts recommend using so-called “ghost tables”: invisible table structures that ensure a consistent layout in Outlook while using normal <div>-based layouts in modern clients. Mailjet advises coding with <div>s and fallback tables so that Outlook users get a reliable structure. Similarly, some semantic HTML5 tags (like <header>, <figure>, <aside>, etc.) or ARIA attributes may not be supported everywhere. As a rule, test your accessible email in major clients (Gmail, Apple Mail, Outlook.com, etc.) and adjust. The goal is to use the best markup you can, while ensuring the email doesn’t break in common inboxes.
  • Test with actual screen readers or checkers. Automated email accessibility checkers can catch obvious issues, but nothing beats a human test. Use tools: for example, Outlook’s built-in Accessibility Checker, the free WAVE extension, or browser devtools. Better yet, try opening your email with a screen reader (NVDA, VoiceOver, Narrator) to hear what a blind user would hear. And double-check contrast with a tool. Apple Mail, Gmail, and Outlook all have fairly good support for alt text and basic markup, so ensure those functions (like alt text reading) actually work.

Side-by-Side Example: Accessible vs. Non-Accessible Email

By now you know the theory. To illustrate, consider the two email designs below. The first email was built entirely as a single image graphic. The second is an improved version. Notice the differences in structure, text, and alt text:

Figure: Non-compliant email example (inaccessible). Here the entire message is a flyer image with no meaningful alt text. A screen reader would only see something like “Flyer image” (or nothing), so all content is lost to visually impaired users. Users cannot select the text, change contrast, or resize it. Essential info (event name, date, call-to-action) is trapped in the image.

Figure: Accessible email example (compliant). This version has the same content but with real text elements and proper image alt text. The headline and details (“Adventure of a Lifetime… Junior Conference 2022”) are coded as text (using <h1>, <p>, etc.), so screen readers can speak them. The header graphic has an alt="The Adventure of a Lifetime with Georgia 4-H – Junior Conference 2022", matching the visible text. The call-to-action (“Register by Aug 1”) and event details are text, not images. This makes the email navigable and understandable by assistive technologies. In short, all information is also present as actual text, so losing the images (e.g. in a blocked-image view) still leaves a coherent message.

These examples highlight key points: Never rely on images to deliver critical text, and always use alt attributes on images. In the accessible version, the screen reader can read all the same details simply by traversing the text and alt tags. In the non-compliant version, none of the important content is accessible.

Compliance Frameworks: WCAG 2.1 and EN 301 549

As mentioned, WCAG 2.1 Level AA is the de facto guide for email accessibility under the EAA. WCAG is the internationally recognized set of guidelines published by the W3C. Although WCAG itself isn’t a law, the EAA makes its key success criteria legally binding in the EU. EN 301 549 is the European standard that supports this: it explicitly “incorporates the WCAG 2.1 AA standard” for digital services. (A new version of EN 301 549 is being prepared for release in 2025 to align fully with the EAA.)

Practically speaking, you should treat an email like a webpage: apply the same WCAG rules. This includes not just what we’ve covered (alt text, headings, contrast), but also other AA criteria like readable language, error identification, etc., wherever relevant. Fortunately, most marketing emails are relatively simple in form. Key things to ensure: headings for navigation (WCAG 2.4.6), descriptive labels for form fields if you have any, and avoiding purely decorative embellishments that aren’t marked as such (WCAG 1.3.1 and 1.1.1).

Finally, note that some countries have their own complementary laws (e.g. Germany’s BITV, France’s RGAA) that align with WCAG. But for cross-border email campaigns in Europe, sticking to EAA/WCAG is the surest path. In summary, if your emails pass WCAG 2.1 AA success criteria, you’ll be well positioned for EAA compliance.

Email Accessibility Checklist (Best Practices)

To help your team remember the essentials, here’s a checklist of best practices for accessible emails under the EAA. Use this when reviewing your email templates or planning new campaigns:

  • Email format: Send HTML emails, not plain-text or RTF. HTML allows semantic markup (headings, lists, etc.).
  • Structure: Use <h1> for the main title/headline, then <h2>, <h3> in logical order. Wrap content in <p> tags, and use <ul>/<li> or <ol> for lists. Avoid using <p> tags just for spacing (use CSS padding/margin instead).
  • Text content: Keep all important info as text, not images. Make sure fonts are at least 14px (12pt) and readable, and choose a simple sans-serif font.
  • Alt text: Every informative image must have a succinct, descriptive alt="...". Decorative images should have alt="" so they are skipped. Do not put meaningful text inside images without also providing it as real text.
  • Contrast: Verify text/background contrast is ≥4.5:1 for normal text (≥3:1 for large/bold text). Use a color-contrast checker tool to confirm. Avoid very light text on light backgrounds or vice versa.
  • Links/buttons: Use descriptive link labels (e.g. “Download Invoice” vs. “Click here”). Every link text should make sense on its own. Similarly, label buttons with their purpose.
  • Keyboard navigation: Ensure tab order is logical. Check that all interactive items (links, buttons, form fields) can be reached with the keyboard and have a visible focus indicator.
  • Tables: If you use tables for layout, add table headers (<th>) and avoid empty cells. (Better yet, use CSS layout for simple structures.) If you present actual data in a table, make sure it has row/column headings.
  • Language: Specify the email’s language with lang="en" (or whatever) on the <html> tag so screen readers pronounce text correctly.
  • Avoid problematic features: Don’t rely on JavaScript or complex ARIA in emails (many clients strip or ignore these). Avoid blinking/scrolling text and other dynamic effects that can cause seizures or readability issues.
  • Test thoroughly: Use accessibility checkers (e.g. WAVE, Axe DevTools) and have someone navigate with a screen reader (VoiceOver on Mac/iOS, NVDA on Windows, etc.). Check your emails in major clients (Gmail, Outlook, Apple Mail) and devices to ensure formatting and alt text survive the rendering.

By systematically applying these guidelines, you’ll cover the main WCAG criteria for emails (structure, text alternatives, contrast, navigation, etc.). Keep this checklist handy for all your email projects.

Call to Action: Taking Steps Now

The EAA’s 2025 deadline is approaching quickly. Don’t wait until it’s an emergency to audit your email templates. Here are immediate action steps:

  1. Audit your current emails. Use an accessibility testing tool or manual review to identify issues in your most critical emails (newsletters, order receipts, password resets).
  2. Fix the high-impact problems first. For example, add alt text to all images and correct any very low-contrast text.
  3. Switch to accessible email templates. Update your email generator or marketing platform with templates that follow best practices (proper tags, CSS, etc.). Many email marketing tools have accessible template libraries or modules you can adopt.
  4. Train your team. Make sure content writers and developers know these rules. Even non-technical team members should avoid pasting images of text or using ambiguous link phrases.
  5. Build ongoing processes. Incorporate email accessibility into your QA/testing checklists. For example, use Outlook’s built-in Accessibility Checker or similar tools before sending major campaigns. Schedule periodic reviews of email content as you would any compliance task.

By preparing now, you turn the EAA from a compliance headache into an opportunity. Accessible emails not only meet EU law but also improve overall user experience and brand reputation. They can increase engagement – after all, if more people can read your message, it’s more effective marketing. Treat this as a worthwhile upgrade rather than a burden.

Call to Action: Audit your email systems today. Use the checklist above to evaluate your top email templates. Plan any necessary redesign or coding work before mid-2025. Remember that email accessibility is part of the broader EU accessibility landscape – so aligning with WCAG 2.1 AA will also serve you under EN 301 549 and other regulations.

In summary, achieving EAA email compliance means building accessible emails Europe across your organization. Follow the guidelines and checklist above to make your marketing and transactional emails inclusive for all users. Taking these steps now will ensure you meet the European Accessibility Act 2025 requirements, avoid fines, and open up your communications to a wider audience.

Sources: Guidelines and data in this post are drawn from EU official releases and recognized accessibility authorities, including industry experts on email compliance. The side-by-side email examples are for illustration of these principles. Use this as a starting point for email accessibility planning under the EAA.

Understanding Authenticated Received Chain (ARC): Benefits, Drawbacks, Implementation, and Use Cases for Email Authentication

Authenticated Received Chain (ARC): Pros, Cons, and Usage

Introduction

Authenticated Received Chain (ARC) is an email authentication protocol designed to address limitations in the existing email authentication landscape, particularly when forwarding emails. ARC allows the verification of email authentication results even when intermediaries modify the message. This blog post delves into the pros, cons, advantages, implementation limitations, and usage scenarios of ARC.

What is ARC?

ARC, short for Authenticated Received Chain, is an email authentication mechanism that works alongside existing protocols like SPF, DKIM, and DMARC. It was introduced to solve the problem of email authentication failures when messages are forwarded through intermediate systems, such as mailing lists or third-party forwarders.

ARC adds a set of headers to the email that records the authentication results from each step in the email’s journey. These headers help the final recipient verify the message’s authenticity despite changes made during transit.

How ARC Works

The introduction of ARC brought the email world three new mail headers:

  • ARC-Authentication-Results (AAR): Combination of an instance number (i) and the results of the SPF, DKIM, and DMARC validation.
  • ARC-Seal (AS): Combination of an instance number (i), a DKIM-like signature of the previous ARC-Seal headers, and the validity of the prior ARC entries.
  • ARC-Message-Signature (AMS): Combination of an instance number (i) and a DKIM-like signature of the entire message except for the ARC-Seal headers.

Upon receipt of email, the receiving mail server applies those three ARC headers to the message. This way, if the message is forwarded or relayed, the original authentication results are preserved. (i.e., if your business sends an email that then gets forwarded three times, these headers preserve the original authentication as without them, the message will fail DKIM.)

When a mail server forwards an ARC-authenticated email, it performs the below functions to preserve the original results:

  1. Copies the “Authentication-Results” field into a new AAR field (starting with i=1) and prepends it to the message.
  2. Calculates the AMS for the message (with the AAR) and prepends it to the message.
  3. Calculates the AS for the previous ARC-Seal headers and prepends it to the message.

When the recipient server receives the message, it will then try to validate an ARC by performing the following steps:

  1. Validates the chain of ARC-Seal headers (no missing entries, all ARC-Seal messages state that the prior ARC entries are valid, etc.).
  2. Validates the newest ARC-Message-Signature (based on the instance number).

If the ARC headers have been modified in any way, the message will show a fail for DKIM authentication. If all mail servers involved in the transmission of the message correctly sign and transmit ARC, then the email should preserve the DKIM authentication results.

Pros and Advantages of ARC

  • Improved Email Deliverability: By preserving authentication results across intermediaries, ARC enhances the chances of legitimate emails reaching their intended recipients.
  • Supports Forwarded Emails: Addresses issues where forwarded emails fail DMARC checks due to changes in the message headers.
  • Complementary to Existing Protocols: Works in tandem with SPF, DKIM, and DMARC, ensuring a more robust authentication process.
  • Transparency and Traceability: Maintains a chain of authentication results, providing greater transparency into the email’s journey.
  • Enhanced Trust: Builds trust among email senders and receivers by demonstrating efforts to authenticate emails effectively.

Cons and Limitations of ARC

  • Complexity in Implementation: Setting up ARC requires careful configuration and a good understanding of email authentication mechanisms.
  • Limited Adoption: ARC is not universally adopted, meaning its benefits are only realized when both senders and receivers support it.
  • Dependence on Intermediaries: ARC’s effectiveness relies on intermediaries correctly implementing and preserving the ARC headers.
  • Risk of Misuse: Improper implementation could allow malicious actors to exploit the chain of trust created by ARC.
  • Resource Intensive: Verifying ARC headers can introduce additional computational overhead for email servers.

Implementation and Usage of ARC

Implementation Steps

  1. Set Up SPF, DKIM, and DMARC: Ensure these protocols are correctly configured as ARC builds upon them.
  2. Enable ARC on Your Mail Server: Configure your mail server to add and validate ARC headers. Popular email platforms like Google Workspace and Microsoft 365 support ARC.
  3. Test Your Setup: Use email testing tools to verify that ARC headers are being added and validated correctly.

Usage Scenarios

  • Email Forwarding: Ensure that forwarded emails pass DMARC checks without being rejected.
  • Mailing Lists: Enable mailing lists to maintain email authentication results, preventing false positives for spam.
  • Third-Party Email Services: Improve deliverability for emails sent through third-party systems.

Conclusion

ARC is a valuable addition to the email authentication ecosystem, addressing the longstanding issue of forwarded email failures. While its adoption is still growing, its ability to enhance email deliverability and transparency makes it an essential tool for organizations that rely heavily on email communication. By understanding the pros, cons, and implementation nuances of ARC, email administrators can take a significant step toward improving their email security and reliability.

Understanding SPF, DKIM, and DMARC: A Simple Guide

Email security is a key part of internet communication. But what are SPF, DKIM, and DMARC, and how do they work? This guide will explain it all in simple terms to make these concepts clearer.

Table of Contents

  1. What Is This Guide For and Why Bother?
  2. Why Choose This Guide?
  3. What This Guide Is Not For
  4. SPF, DKIM, and DMARC: Simplified
  5. Real World Examples of where SPF, DKIM, and DMARC are used
  6. Now I Know These Things, What’s Next?
  7. Checking Your SPF, DKIM, DMARC Status
  8. FAQ’s with SPF, DKIM and DMARC
  9. Wrapping Up
  10. Contributing
  11. Sharing is Caring
  12. Contact
  13. References

What Is This Guide For and Why Bother?

If you are involved in developing, supporting, or maintaining an application that sends emails, this guide is a must read. This guide is your key to peace of mind, knowing that your emails will reach your customers as intended and your domain is shielded from abuse from cybercriminals and spammers. It’s about ensuring they reach the intended destination – the recipient’s inbox, not the spam or junk folder. For instance, You’ve built an e-commerce application or a SaaS platform that sends transactional emails like order confirmations or password resets or important customer notification emails. These emails are crucial touchpoints for your customers. But what if they never see them? What if these important communications end up in spam or junk? While email is one of the most common communication channels, it’s also a favorite target for cybercriminals and a playground for spammers. Here are some real-world examples of how they can abuse email systems:

  • Phishing Attacks: A cybercriminal wants to steal sensitive information from the customers of a well-known bank. The criminal could spin up or use a compromised server to send emails that appear to come from the bank’s domain, asking customers to update their account information. If the bank hasn’t implemented SPF, the email could pass the receiving server’s checks and land in the customer’s inbox. The customer, thinking the email is from their bank, clicks the link and enters their login details on a fake website controlled by the criminal. The criminal can now access the customer’s bank account.

  • Brand Impersonation: A cybercriminal could impersonate a popular e-commerce platform and send emails to users asking them to confirm their purchase of an expensive item. The email could contain a link to a fake customer support page where the user is asked to enter their login details to cancel the purchase. If the e-commerce platform hasn’t implemented DKIM, the email could pass the receiving server’s checks and land in the user’s inbox. The user, thinking the email is from the e-commerce platform, enters their login details on the fake page, giving the criminal access to their account.

  • Business Email Compromise (BEC): A cybercriminal could impersonate a company’s CEO or another high-ranking official and send an email to the finance department, asking them to make a payment to a new vendor. If the company hasn’t implemented DMARC, the email could pass the receiving server’s checks and land in the finance department’s inbox. The finance department, thinking the email is from the CEO, could make the payment to the criminal’s bank account.

By understanding and implementing SPF, DKIM, and DMARC, you can protect your domain from being used in these types of attacks, safeguard your customers and employees, and maintain your reputation. So, why bother? Because your emails matter, your customers matter, and your reputation matters.

Why Choose This Guide?

With so many articles out in the internet why should I choose this guide? This guide stands out for its simplicity, clarity, and convenience. It demystifies SPF, DKIM, and DMARC with clear explanations and examples avoiding the technical jargon as much as possible. Hosted on GitHub, it integrates seamlessly with your development environment, providing quick access to information right from your IDE (visual studio code ,etc.) or command line. Plus, it’s a document that will stay in Github and guaranteed that won’t go anywhere that can be edited by you or anyone or the community to ensure it stays updated and relevant.

What This Guide Is Not For

While this guide aims to simplify SPF, DKIM, and DMARC, it’s not intended to be a comprehensive guide about these topics. It’s not a guide for setting up an email server, nor does it cover advanced topics like encryption or secure email gateways.

SPF, DKIM, and DMARC: Simplified

SPF (Sender Policy Framework)

SPF: It’s like a list of friends who can send emails for you. The SPF Record is this list. If an email says it’s from you but it’s not sent by a friend on your list, it’s probably not really from you. As the owner of a domain, you can use SPF to create a list of ’email friends’ – these are the mail servers that are allowed to send emails on your behalf. This helps stop people who aren’t your ’email friends’ from pretending to be you. The SPF Record, a DNS TXT record, is where you keep this list of ’email friends’. The DNS TXT record for an SPF your ’email friends’ typically looks like this:

v=spf1 ip4:123.123.123.123 ~all

Here’s the command I usually run to fetch that:

dig TXT example.com

DKIM (DomainKeys Identified Mail)

DKIM: It’s like a secret note inside your emails. When you send an email, you put a secret note inside. This note is made using a special secret code only you know. When your email arrives, the receiver checks the secret note using a public code that everyone knows. This public code is stored in a place called the DKIM Record. If the secret note matches the public code, the email is really from you and hasn’t been changed. This helps stop bad people from pretending to send emails from you or changing your emails. This public code, also known as a public key, is stored in a DNS TXT record known as the DKIM Record, which is accessible to everyone. It’s like the decoder for your secret code. The DNS TXT record, where the public code (or public key) for DKIM is stored, typically looks like this:

v=DKIM1; k=rsa; p=NICfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBolTXCqbxwoRBffyg2efs+Dtlc+CjxKz9grZGBaISRvN7EOZNoGDTyjbDIG8CnEK479niIL4rPAVriT54MhUZfC5UU4OFXTvOW8FWzk6++a0JzYu+FAwYnOQE9R8npKNOl2iDK/kheneVcD4IKCK7IhuWf8w4lnR6QEW3hpTsawIDAQ0B"

Here’s the command I usually run to fetch that:

dig TXT selector1._domainkey.example.com

Note: Replace selector1 with your actual selector, and example.com with your actual domain. This command will fetch the DNS TXT record where your public code is stored.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC: It’s like the boss of SPF and DKIM. It takes the rules from SPF and DKIM and makes a big rule book. This rule book tells everyone what to do if an email from your domain doesn’t follow the rules. For example, one rule could be to send a report if an email doesn’t pass the checks. The DMARC Record, a place everyone can see, holds this rule book. If an email passes the SPF and DKIM checks, the receiver then looks at the DMARC rule book to decide what to do with the email. They might follow the rule to send a report, or they might follow another rule depending on what your rule book says. DMARC allows domain owners to declare their rules in the rule book. This rule book, stored in the DMARC Record, a DNS TXT record, specifies your DMARC policies and how receivers should handle mail that violates these rules. If both SPF and DKIM checks pass, the receiver then checks the DMARC rule book to decide what to do with the email. The DNS TXT record for DMARC ‘rule book’ typically looks like this:

v=DMARC1; p=none; rua=mailto:postmaster@example.com

Here’s the command I usually run to fetch that:

dig _dmarc.example.com TXT

Real World Examples of SPF, DKIM, and DMARC Are Used

Let’s look at how SPF, DKIM, and DMARC work in real-world example scenarios:

  • Mobile Apps: Mobile apps that send emails, such as a fitness app sending workout summaries or a banking app sending transaction alerts, also use SPF, DKIM, and DMARC. When the app sends an email, the receiving server checks if the sending server’s IP is in the SPF record of the sender’s domain. It then uses the DKIM record to verify the email’s DKIM signature. If both checks pass, the server applies the DMARC policy to decide what to do with the email. This ensures that the emails reach the user’s inbox and not the spam folder, and protects the app’s reputation by preventing email spoofing.

  • Email Service Providers: Providers like Gmail, Yahoo, and Outlook use SPF, DKIM, and DMARC to authenticate incoming emails. For instance, when an email arrives, Gmail checks if the sending server’s IP is in the SPF record of the sender’s domain. It then uses the DKIM record to verify the email’s DKIM signature. If both checks pass, Gmail applies the DMARC policy to decide what to do with the email.

  • Social Media Platforms: Social media platforms like LinkedIn, Facebook, or Twitter that send notification emails also use SPF, DKIM, and DMARC. When a user receives a notification email, their email provider checks if the sending server’s IP is in the SPF record of the social media platform’s domain. It then uses the DKIM record to verify the email’s DKIM signature. If both checks pass, the provider applies the DMARC policy to decide what to do with the email. This ensures that the emails reach the user’s inbox and not the spam folder, and protects the social media platform’s reputation by preventing email spoofing.

  • Businesses: Businesses use SPF, DKIM, and DMARC to protect their email communication and brand reputation. For example, a business might send promotional emails to its customers. By implementing SPF, DKIM, and DMARC, the business ensures that its emails are not marked as spam and that its domain is not used for email spoofing.

  • Government Agencies: Government agencies use SPF, DKIM, and DMARC to secure their email communication and prevent phishing attacks. For instance, a government agency might send notifications to citizens. By using SPF, DKIM, and DMARC, the agency ensures that its emails reach the citizens’ inbox and that cybercriminals cannot send phishing emails that appear to come from the agency.

Now I Know These Things, What’s Next?

Now that you’ve learned the basics of SPF, DKIM, and DMARC, you might be thinking about using these tools to make your emails more secure. Here’s a simple guide to help you get started:

  1. Identify the Email Address and Domain: First, you need to know the email address and domain your app uses. You’ll need to add SPF, DKIM, and DMARC records to this domain. A simple way to find this out is by sending an email from your app to yourself. For example, you could sign up for an account on your site and click on ‘forgot password’ to receive an email.

  2. Current Status: Next, check if you already have SPF, DKIM, and DMARC records. If you do, make sure they’re set up correctly. You can learn how to do this in the next section, ‘Checking Your SPF, DKIM, DMARC Status’.

  3. Domain Access: Make sure you have the rights to change the DNS records of your domain. You’ll need this to add SPF, DKIM, and DMARC records. If you don’t have access, you’ll need to request the person who does to add these records for you.

  4. DMARC Monitoring: Once you’ve set up DMARC, you’ll need to keep an eye on DMARC reports to make sure everything’s working as it should and fix any problems. Decide who will do this and which email address will receive the DMARC reports.

The usual order is to set up the SPF record first, then DKIM, and finally DMARC.

Checking Your SPF, DKIM, DMARC Status

This is a straightforward with tools like MXToolbox and DMARCTester. Here’s how you can use these tools:

  1. MXToolbox:
    • Visit https://mxtoolbox.com/
    • Use the ‘SPF Record Lookup’, ‘DKIM Record Lookup’, and ‘DMARC Record Lookup’ tools to check the respective records for your domain.
  2. DMARCTester:
    • Visit https://www.dmarctester.com/
    • This site offers two ways to check your email security:

      • Send an Email: The site generates a unique email address for you. You can then send an email from your application or mail server to this address.

      • Paste Email Headers: Alternatively, you can send an email from your application to your own email address, then copy the email headers and paste them into the tool.

Remember, these checks help you understand what’s missing or needs improvement to enhance your email security and reputation, make sure you take note of that and take action. Note: When using online tools, only share what’s needed. Always check the site’s privacy rules to keep your info safe. I’m sharing these tools because they’re helpful, not because I am affiliated with them.

FAQ’s with SPF, DKIM and DMARC

  1. What email address should I use for DMARC reporting? It’s a good idea to use an email address that multiple people can check. This is often a shared mailbox. Ideally, this email address should be from the same domain that you’re setting up DMARC for. If you decide to use an email address from a different domain, you’ll need to add an extra step: You’ll have to add a special record (called a DNS TXT record) to authorize the other domain to receive DMARC reports.

  2. What’s the difference between ~all, -all, ?all, and +all in an SPF record? These are used to tell receiving servers what to do if an email comes from a server that isn’t listed in your SPF record.

    • ~all (SoftFail): This means “It’s okay if the server isn’t on my list, but be aware that it might not be legit.” The email will still be accepted, but it might be marked as suspicious. This is often used when you’re still testing your SPF record or making changes to it.

    • -all (Fail): This means “Only accept emails from servers on my list. Reject everything else.” This is used when you’re sure of all the servers that should be sending emails for your domain.

    • ?all (Neutral): This means “I’m not saying whether servers should be on my list or not. Treat the email as you normally would.” This doesn’t really give any instructions about how to handle the email, so it’s not used very often.

    • +all (Pass): This means “Accept emails from all servers, even if they’re not on my list.” This isn’t recommended because it could allow spammers to send emails that look like they’re from your domain.

    The choice between these depends on how strictly you want to enforce SPF rules for your domain. It’s generally recommended to use ~all while testing or setting up your SPF record, and switch to -all once you are confident that your SPF record is correct.

  3. Can I set up DMARC without SPF? Technically, you can, but it’s not a good idea. DMARC is like a security guard for your emails. It uses two tools, SPF and DKIM, to check if an email is really from you. If an email fails both the SPF and DKIM checks, it also fails the DMARC check. If you set up DMARC without SPF, it’s like the security guard is missing one of its tools. It can still use DKIM to check emails, but it won’t be as effective. SPF isn’t perfect and can’t stop all fake emails on its own. That’s why it’s best to use it together with DKIM and DMARC. This gives you a more complete email security system.

  4. I’ve looked at an email header and I see multiple SPF fails and some SPF passes. Which one should I believe? Think of an email header like a story. The most recent events are at the top, and the oldest events are at the bottom. So, the original sender’s information is usually towards the bottom of the header. If you see multiple SPF fails and a couple of SPF passes, it might feel like the story is getting confusing. But don’t worry! You should trust the SPF check that’s related to your domain or the domains that you trust (like your ‘friends list’). The other SPF checks are for other domains that were part of the email’s journey, and their pass or fail status doesn’t affect your domain’s SPF status.

Wrapping Up

Just like a secret handshake, SPF, DKIM, and DMARC are the hidden heroes of email security. They’re the reason your email recipients can trust messages from your domain. So, the next time you hit ‘send’, remember that these three musketeers are working tirelessly behind the scenes to keep your email safe.

Contributing

Spotted a mistake or missing info in this guide? Don’t be shy! Raise an issue or better yet, fork this repo and raise a PR. Your contributions help make this guide better for everyone.

Sharing is Caring

You’re welcome to share, clone, fork, or bookmark this content. All we ask is that you give credit where it’s due 🙂 “Understanding SPF, DKIM, and DMARC: A Simple Guide” by Nicanor II Flavier, used under CC BY 4.0. To view the original material, visit https://github.com/nicanorflavier/spf-dkim-dmarc-simplified

Contact

If you have any questions or suggestions, feel free to reach out. You can find my contact details on my GitHub profile https://github.com/nicanorflavier

References

Here are some useful resources if you want to learn more about SPF, DKIM, and DMARC:

Courtesy: https://github.com/nicanorflavier/spf-dkim-dmarc-simplified.git

What’s Included in Each Google Workspace Plan

As G Suite has integrated more communication and collaboration tools, it has been rebranded to Google Workspace. All Google Workspace plans provide a custom email for your business and include collaboration tools like Gmail, Calendar, Meet, Chat, Drive, Docs, Sheets, Slides, Forms, Sites, and more.

Some of the Google Workspace plans available are listed below:

Business Starter

This plan includes custom and secure business email, security and management controls, as well as standard support. Each user is provided with 30GB of cloud storage and video meetings can include up to 100 participants.

Business Standard

The Business Standard plan includes all the features of the Business Starter plan, with users provided with a larger cloud storage capacity (2TB). Video meetings can include up to 150 participants, with recording capability.

Business Plus

For enhanced security and management controls, as well as eDiscovery and retention, this plan provides greater control and peace of mind. Video meetings of up to 250 participants, including recording and attendance tracking capability. Each user is provided with 5TB of cloud storage.

Each plan will give you access to your own email account and all the Google Workspace productivity and collaboration tools. The main differences lie in storage allowance, security features, and the level of administrative control you have over the products.

Google Workspace Business Starter Google Workspace Business Standard Google Workspace Business Plus Google Workspace Enterprise
Price $6/user/month $12/user/month $18/user/month Contact sales
Professional email (using your own domain) Yes Yes Yes Yes
Google Workspace Products (Gmail, Drive, Docs, Sheets, Slides, Calendar, Hangouts, Meet, Forms, Sites) Yes Yes Yes Yes
File storage 30 GB/user 2 TB/user 5 TB/user Unlimited
24/7 support Yes Yes Yes Yes
App Maker No Yes Yes Yes
Max. number of video participants 100 150 250 250
Ability to record and save video & voice conferences No Yes Yes Yes
Live-streaming on Meet Video No No No Yes
Cloud Search (advanced enterprise-wide search through Gmail, Drive, Docs, etc.) No Yes Yes Yes
Advanced enterprise controls (data loss prevention, security center, security key management, etc.) No No No Yes
Alerts for changes to Drive documents No Yes Yes Yes
Google Vault security (archiving for mail and chat messages, export features, etc.) No No Yes Yes
Ability to set rules for device management No No No Yes

Which Google Workspace Plan Should You Choose?

Google Workspace Business Starter

This plan would be a good option if:

  • You’re a freelancer, solopreneur or small business owner who manages a small team (i.e. less than 5 employees)
  • You want an email address on your own domain
  • You want to run your office tools out of Google (e.g. as opposed to Microsoft Office)
  • You don’t work with large file formats and don’t need a huge amount of space to store files and emails
  • You don’t need archiving for your emails and chat messages, or advanced admin and security controls

However, if you have a bigger team and/or don’t think the 30 GB of personal storage will cut it, then it’s worth considering one of the higher plans.

Google Workspace Business Standard

The $6/user/month price difference between Google Workspace Business Starter and Business Standard means that the Standard plan may not be a realistic option for some businesses. However, we’d recommend this plan if:

  • You manage a medium-to-large sized team
  • You want access to all the features of Google Workspace Business Starter, but also want email and message archiving (Google Vault)
  • You don’t want to worry about running out of storage space for your files
  • Easily syncing and sharing files across teams/the company is important to you
  • You plan to use Google Hangouts for video conferencing and would have less than 150 participants on any call
  • You don’t need advanced admin and security controls (e.g. data loss prevention, security key management)

Of course, if you need even greater control and more advanced security features, then Business Plus would be the way to go.

Google Workspace Business Plus

At $18/month/user, this plan is directed at larger businesses. We’d recommend it if:

  • You are in need of more advanced security features
  • 2 TB per user isn’t enough for you. The Business Plus plan allows for 5 TB per user
  • You regularly host very large video conferences with up to 250 participants

Google Workspace Enterprise

This is ideal for businesses and enterprises that need the features offered by Google Workspace Business Plus, but also:

  • Have larger teams, and therefore require greater admin and security controls over their Google Workspace apps
  • Need advanced security features such as device management rules, security key management and data loss prevention
  • Aside from having access to email archiving via Google Vault, need to be able to integrate with third-party archiving tools like Barracuda or Mailstore

The good thing is that you can purchase different plans for different users within your business. For example, if you only want Enterprise for some of your users, you don’t have to commit your entire team to it. This could help you reduce your monthly cost significantly.

There are also special plans available for schools (Google Workspace for Education and Google Workspace Enterprise for Education), and non-profits (Google Workspace for Non-profits, which is free of charge).

Plans can be billed monthly or annually. Discounts may also apply to annual plans, but generally only if you sign up through a Google representative.