Discovering Who's Pointing SPF Records at Your Domain with SPF Macros

Ever Wondered Which Domains Include Your SPF Record?

If you're a SaaS vendor, email service provider, or any organisation whose domain gets included in other companies' SPF records, you've likely asked yourself: "Who exactly is pointing their SPF records at my domain?"

SPF (Sender Policy Framework) allows domain owners to publish a list of IP addresses or subnets authorised to send email on their behalf. When another organisation adds your domain via an include: mechanism, they're essentially trusting your infrastructure to send mail as them. But there's no built-in way to discover the reverse — who's trusting you.

Until now.

The Problem: No Reverse Visibility

Imagine you're vendora.example.com, a company that sends transactional email on behalf of clients. Your clients — let's say example.org — add something like this to their SPF record:

v=spf1 include:vendora.example.com ~all

When someone receives an email from example.org, their mail server checks this record to verify whether the sending server is allowed to act on their behalf. The receiving server follows the include: chain, eventually looking up vendora.example.com's SPF record to check the sending IP.

But as vendora.example.com, you have no native way to see which domains have included you. You might know your customers from your own records, but what about:

• Former customers who never cleaned up their DNS?
• Unauthorised parties referencing your domain?
• Domains you didn't even know about?

The Solution: SPF Macros + spf.guru

SPF records support macros — dynamic placeholders that get expanded at query time by the receiving mail server. Two macros are key here:

Macro	Meaning
%{ir}	The reverse IP address of the connecting (sending) mail server
%{o}	The original domain from the SMTP MAIL FROM (envelope sender)

By cleverly embedding these macros into your SPF record and pointing them at a logging service like spf.guru, you can capture who's including your domain in real time.

How It Works: Step by Step

1 Add the macro to your domain's SPF record

If your domain is vendora.example.com, update your SPF record to include the spf.guru macro:

v=spf1 include:i.%{ir}._d.%{o}.my.spf.guru ~all

(You can add your other mechanisms alongside it, of course.)

2 A client includes your domain

Your client, example.org, has the following in their SPF record:

v=spf1 include:vendora.example.com ~all

3 An email is sent from example.org

When a mail server at IP 203.0.113.42 sends an email with a MAIL FROM of user@example.org, the receiving server performs an SPF check. It:

1. Looks up the SPF record for example.org
2. Sees include:vendora.example.com
3. Looks up the SPF record for vendora.example.com
4. Finds the macro include:i.%{ir}._d.%{o}.my.spf.guru
5. Expands the macros at query time:
   • %{ir} becomes 42.113.0.203 (the reversed IP)
   • %{o} becomes example.org (the original envelope sender domain)
6. Performs a DNS lookup for:

i.42.113.0.203._d.example.org.my.spf.guru

4 spf.guru logs the query

The DNS query hits spf.guru's nameservers, which log the request. Now you have a record showing:

• The sending IP (from %{ir}): 203.0.113.42
• The original domain (from %{o}): example.org
• Pass/Fail result

5 View your results

Visit https://spf.guru to see all logged results, giving you a clear picture of which domains are including your SPF record and which IPs are sending on their behalf.

Why This Matters

This approach gives you powerful visibility:

• 🔎 Discover unknown includers — Find domains referencing your SPF record that you didn't know about.
• 🧹 Identify stale references — Spot former clients who still have your domain in their SPF records.
• 🛡️ Security monitoring — Detect unauthorised use of your sending infrastructure.
• 📊 Audit your footprint — Understand the full scope of your email sending reputation impact.

Important Considerations

⚠️ DNS Lookup Limits: SPF records are limited to 10 DNS lookups per evaluation. The spf.guru macro adds to this count, so make sure your clients' SPF records (and your own) don't exceed this limit.

ℹ️ Macro Support: While SPF macros are part of the RFC 7208 specification, not all receiving mail servers fully support macro expansion. In practice, most major providers do.

• Privacy: Be mindful that you're logging sending IPs and domain names. Make sure this aligns with your privacy policies.
• Response behaviour: The spf.guru service will respond to DNS queries in a way that doesn't break your SPF evaluation — check their documentation for details on pass/fail behaviour.

Quick Setup Checklist

• ✅ Visit https://spf.guru no need to set up an account
• ✅ Add include:i.%{ir}._d.%{o}.my.spf.guru to your domain's SPF record
• ✅ Keep your existing SPF mechanisms (IP addresses, other includes, etc.)
• ✅ Verify the record with an SPF checker tool
• ✅ Monitor the spf.guru dashboard for incoming data

Wrapping Up

SPF macros are an underutilised but powerful feature of the SPF specification. By combining them with a logging service like spf.guru, you gain reverse visibility into your SPF ecosystem — something that's traditionally been a blind spot for email infrastructure teams.

If you're a vendor or service provider whose domain appears in other organisations' SPF records, this simple addition to your DNS can unlock invaluable insights into who's relying on your sending infrastructure.

Stop Bypassing DMARC: A Supply Chain Reality Check

DMARC isn’t the problem—how we respond to failed authentication often is.

TL;DR: Don’t add bypasses when supply-chain email fails DMARC. Report it to the sender and ask them to fix their authentication. Most “legit” failures trace back to shadow IT or unsanctioned senders, not broken DMARC.

For years, organisations have looked at DMARC with a mix of admiration and fear. On one hand, it’s one of the most effective controls to protect customers, partners, and employees from email impersonation. On the other, it’s often blamed for “breaking” legitimate business email.

The truth? More often than not, the problem isn’t DMARC. It’s how we respond when email from the supply chain doesn’t align.

---

The Easy Way Out: Adding Bypasses

When an important invoice, purchase order, or system notification is blocked because of DMARC, the reflex in many IT teams is to add a bypass. After all, business continuity matters. The sender insists the mail is “legitimate,” so why not?

Here’s the catch: bypasses introduce risk at scale. Once you start allowing mail that fails authentication, you’re effectively unravelling the very purpose of DMARC—keeping bad actors out of your users’ inboxes.

• Every bypass weakens your email security posture.
• Exceptions pile up and become hard to track or remove.
• Attackers learn to exploit known “allow” paths.

The Perception Problem

There’s a persistent narrative that “lots of organisations mess up their DMARC records” and that this causes widespread delivery issues. While misconfigurations do happen, context is everything:

• If a domain owner sets p=quarantine or p=reject, they’ve made a deliberate risk decision.
• From the outside, you can’t know if the “blocked” email was sanctioned or came from shadow IT—a platform sending on behalf of the organisation without security or data-privacy onboarding.

In other words, what looks like a false positive may actually be a false assumption.

The Shadow IT Grey Zone

This is the greyest of grey areas. That “legitimate” email may be:

• A SaaS tool bought on a corporate credit card.
• A system that never went through a security review.
• An integration no one in IT approved or onboarded.

In many cases, the sender’s own IT and security teams don’t authorise the source. Which means the sender will face the same DMARC “issues” with everyone they email—not just you.

Yes, Edge Cases Exist

Are there times when a sanctioned application has been genuinely missed during onboarding and the sender is enforcing DMARC? Of course. DMARC, like any control, isn’t immune to operational oversights.

But best practice is simple: report the issue to the sending organisation. Let their IT and security teams validate the source, correct SPF/DKIM/DMARC, and update their records accordingly—so the fix scales to all recipients, not just you.

Why This Matters

• Security: Bypasses open doors for spoofing and business email compromise (BEC).
• Consistency: Exceptions create inconsistent delivery and unpredictable support load.
• Scale: Fixing at the sender side benefits every recipient; a local bypass only helps you—and increases your risk.

DMARC is only as strong as the weakest exception.

What to Do Instead (Playbook)

1. Hold the line: Don’t create allow-lists or bypasses for failed authentication.
2. Notify the sender: Share the error and message sample (headers, authentication results).
3. Ask for basics: Confirm the sender’s authorised platforms and whether IT/security sanctioned them.
4. Verify fixes: Look for correct alignment: SPF (envelope/HELO), DKIM (aligned signing domain), and a valid DMARC policy.
5. Close the loop: Test again and remove any temporary, time-boxed mitigations.

Helpful Language for Stakeholders

“We don’t add bypasses for failed DMARC. Please have your IT/security team confirm the sender is authorised and ensure SPF/DKIM align with your DMARC policy. Once corrected, delivery will work for all recipients, not just us.”

---

Final Thought

Instead of defaulting to bypasses, flip the script: treat failures as a supply-chain improvement opportunity. Push vendors and partners to properly onboard their sending systems. Recognise that DMARC isn’t the enemy—shadow IT is.

When you protect the integrity of your email channel, you’re not just defending your organisation—you’re raising the bar for everyone in your supply chain.

If you found this useful, consider sharing with your security and procurement teams—DMARC success is a team sport.

What’s a “User-Agent” Anyway?

What’s a “User-Agent” Anyway?

Whenever your web browser, mobile app, or an automated script requests a web page, it quietly introduces itself with a User-Agent header. Think of it as the digital equivalent of saying, “G’day, I’m Chrome on a Windows laptop” when you walk through the door of a website.

Here’s a typical example (no need to memorise it!):

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

Each chunk tells the server something about the requester:

• Browser / Engine – Chrome/124…
• Operating System – Windows NT 10.0
• Architecture – Win64; x64

Servers use that information to decide which content or layout to send back (for example, a mobile-friendly page for a phone).

---

Why Cyber-Security Folks Care About User-Agents

Because the header is just text, any tool can claim to be anything. That makes the User-Agent string both useful and potentially dangerous.

1 · Spotting “Good” Bots vs “Naughty” Bots

Security teams keep lists of known, legitimate scanners—think Microsoft Defender SmartScreen or Google’s Safe Browsing crawler. These bots announce themselves with recognisable User-Agents such as:

• Mozilla/5.0 AppleWebKit/… +https://safebrowsing.google.com/
• Mozilla/5.0 (compatible; MS Defender SmartScreen URL Reputation)

Firewalls and e-mail gateways can then decide, “If it’s that scanning tool, let it through; if it’s something pretending to be Chrome 99 on Windows 95, maybe block or sandbox it.”

2 · Reducing “Single-Click” Mishaps

Imagine you receive an e-mail saying, “Approve expenses by clicking here.” Corporate web-filters might pre-click (or “prefetch”) that link to scan it for malware. That protective click could accidentally approve the request on your behalf if the app trusts the first visitor.

Risky Design	Safer Design
A link that performs a sensitive action via GET (one click)	The link leads to a page that asks for confirmation or a POST/PUT with a CSRF token
No distinction between a user’s browser and an automated scanner	Check the User-Agent (plus IP range, headers, timing) and require a logged-in session

User-Agent alone isn’t fool-proof, but it’s a quick first check—“Does this look like our employee’s browser or a known scanning engine?”

3 · Phishing-Simulation Campaigns

Security-awareness vendors send test phishing e-mails to staff. Their links often record the User-Agent so the report can say:

“Jess clicked on the lure from an iPhone running Safari 17.”

Teams use that data to tune training. For example, if 80 % of clicks came from mobile devices, the next awareness module should highlight mobile red flags.

4 · Incident Response & Threat Hunting

Log files packed with User-Agents help responders answer questions like:

• When did the attacker start probing? – A sudden flood of sqlmap/1.7 strings reveals automated SQL-injection sweeps.
• Which systems are compromised? – Spotting a weird User-Agent beaconing to an external server can help trace infected endpoints.

---

How Attackers Abuse the Header

Tactic	Example	Why It Matters
Spoofing	Malware sets its User-Agent to Mozilla/5.0 … Chrome/124…	Blends in with normal traffic to dodge simple filters.
Fingerprinting	Evil site inspects every detail (CPU i686, Locale en-AU)	Builds a unique profile to follow you even without cookies.
Force-Click Exploits	Attacker e-mails a link that auto-approves an action; they rely on corporate scanners hitting it first	The victim’s security tool becomes the unwitting clicker.

---

Practical Tips for Beginners

1. Never trust the User-Agent alone. Validate sessions with tokens, CAPTCHAs, or multifactor prompts for sensitive actions.
2. Log it anyway. Even if it can be faked, patterns over time are gold for threat hunting.
3. Sandbox first-click actions. If your mail gateway or browser plugin pre-scans links, ensure downstream apps require an extra confirmation step.
4. Use allow-lists judiciously. Maintain a catalogue of genuine security scanners (Defender, CrowdStrike, Proofpoint, Mimecast, etc.) and apply looser rules only to those User-Agents and their known IP ranges.
5. Stay updated. Browsers are moving towards Client Hints (shorter, privacy-friendly headers). Keep an eye on how your tooling parses those.

---

Wrapping Up

The humble User-Agent string is a small line of text that packs a punch. For web developers, it’s a way to serve the right layout; for cyber-defenders, it’s another clue to separate friend from foe. Treat it as a helpful hint, not gospel truth, and combine it with solid authentication and logging. That way, whether it’s a real user approving expenses or a phishing simulator prodding for gaps, you’ll know who’s truly knocking at your digital front door.

Why DMARC Matters: How Modern Email Platforms Enforce It to Stop Spoofing

Email remains the #1 channel attackers abuse for phishing, impersonation and fraud. The industry-standard defence is the trio of SPF, DKIM and DMARC. Domain owners publish the policy, but here’s the crucial bit:

The responsibility for enforcing DMARC sits with the receiving mail servers—and the major cloud platforms already honour DMARC out of the box.

Who Actually Enforces DMARC?

Publishing a DMARC record doesn’t block spoofing on its own. DMARC works when the recipient’s mail system checks and enforces it. That’s exactly what the dominant email platforms do today:

Receiving Platform	DMARC Enforcement	Notes
Microsoft 365 (Exchange Online)	✅ Enabled by default	Built-in SPF, DKIM and DMARC validation on ingress
Google Workspace (Gmail)	✅ Fully enforced	Strict SPF/DKIM checks with DMARC policy honouring
Yahoo / AOL (Verizon Media)	✅ Enforced aggressively	Early DMARC adopters; strong stance against spoofing
Apple iCloud Mail	✅ DMARC-aware	Treats failing DMARC messages as suspicious
Secure Email Gateways (Mimecast, Proofpoint, Cisco, etc.)	✅ Standards-compliant	DMARC checks are table stakes for modern gateways

Practical takeaway: Because most business and consumer mail is received by these platforms, the vast majority of inboxes already enforce your DMARC policy.

Adoption at Scale: Microsoft 365, Google Workspace & Co.

• Microsoft 365 serves hundreds of millions of commercial mailboxes globally. Exchange Online validates SPF/DKIM and enforces DMARC policies by default.
• Google Workspace / Gmail powers more than a billion consumer mailboxes and millions of businesses; DMARC is first-class and strictly applied.
• Other majors (Yahoo/AOL, Apple, Outlook.com) and leading email security providers also honour DMARC by default.

In short, if your organisation emails customers, partners or staff using mainstream providers, your published DMARC policy is being read and enforced at the other end.

What About Legacy or Unpatched On-Prem Mail Servers?

Some legacy on-premises MTAs (e.g. very old Exchange versions or unmaintained open-source stacks) may not fully validate DMARC. However, if a server is so old it can’t honour DMARC, it almost certainly has a long list of other security vulnerabilities—missing patches, weak TLS, outdated auth, and limited phishing controls. These environments are now the exception, not the norm, and most are fronted by secure gateways that do enforce DMARC.

Stopping Spoofing: SPF + DKIM + DMARC

• SPF: Verifies the sending IP is authorised for the domain.
• DKIM: Cryptographically signs the message to prove integrity and domain control.
• DMARC: Ties it together—requires alignment and tells receivers what to do on failure (none, quarantine, reject).

Together, these form the industry solution for eliminating direct domain spoofing across modern inboxes.

Stronger Enforcement in the Last 12–18 Months

Major receivers have tightened the screws:

• Google & Yahoo: Tougher requirements for bulk senders; unauthenticated mail is throttled, spam-foldered, or rejected.
• Microsoft: Increased scrutiny and filtering of non-aligned, non-authenticated messages that attempt domain impersonation.
• All majors: Ongoing nudges towards proper SPF/DKIM/DMARC hygiene, improving safety across the ecosystem.

What This Means for You

• Publish DMARC and aim for p=quarantine or p=reject once you’ve validated legitimate senders.
• Authenticate everything (marketing platforms, CRMs, ticketing tools, finance systems) with SPF and DKIM, aligned to your primary domain or subdomains.
• Monitor reports (DMARC RUA) to see who’s sending with your domain and fix gaps before enforcing.

Because receivers already honour DMARC, setting a strong policy immediately reduces successful spoofing against your brand.

Bottom Line

DMARC isn’t just a DNS record—it’s a powerful instruction that modern mail platforms follow by default. In a world dominated by Microsoft 365, Google Workspace and leading security gateways, SPF + DKIM + DMARC is the proven, widely enforced way to stop direct domain spoofing and protect trust.

---

Tip: If you’re still migrating from legacy systems, put a secure email gateway in front—or accelerate your move to cloud email—to ensure DMARC is fully enforced on inbound mail.

Why SPF Soft‑Fail (~all) Is the Smarter Choice for Deliverability

When you publish an SPF record with a hard‑fail (-all), you’re telling every receiver to reject mail from any IP not explicitly authorised. It sounds secure—but it can do more harm than good. In many real‑world scenarios, a soft‑fail (~all) policy delivers the same security under DMARC while avoiding collateral damage to legitimate mail flows. Here’s why staying in soft‑fail often makes the most sense.

1. SPF’s Bypass Vulnerability

SPF checks only the envelope sender (MAIL FROM), not the visible “From:” header. An attacker can exploit this by using a domain they control in the envelope, yet spoof your brand in the header—completely bypassing SPF’s intended protection. DMARC addresses this gap by requiring alignment, but it underscores that SPF alone is never a standalone defence.

2. Under DMARC, “Hard” = “Soft”

Once DMARC is active, any SPF result aside from an aligned “pass” will break SPF alignment—whether it’s -all, ~all or ?all. The receiving system then defers to DKIM or DMARC’s own policy (none, quarantine, reject). In practice, hard‑fail offers no extra benefit under DMARC.

3. The Relaying (Forwarding) Problem

Legitimate forwarding or relaying services—common in multi‑domain setups—break SPF. A forwarded email often arrives from an IP not listed in your SPF, triggering a hard‑fail. With -all, that message is bounced before DKIM or DMARC can save it. Soft‑fail, however, allows the mail through for full authentication checks, ensuring genuine mail survives forwarding.

4. RFC‑Mandated Caution on Early Rejection

The DMARC specification warns that a hard‑fail may cause some receivers to reject mail before DMARC and DKIM can be evaluated. You could lose perfectly legitimate, DKIM‑signed messages simply because SPF blocked them too early.

5. Domain Reputation Isn’t Improved by -all

There’s no evidence that hard‑fail boosts your sending reputation—any “reputation” gain from blocking illegitimate mail is outweighed by the spikes in bounces and NDRs you’ll generate. Soft‑fail avoids those bounces, keeps your bounce rate in check, and still provides the same DMARC‑driven security.

6. Recommended Email Hardening Workflow

1. Publish SPF with ~all to collect data without breaking flows.
2. Deploy DMARC (start with p=none), review reports to identify missing senders.
3. Enable DKIM signing for all legitimate sources and ensure alignment.
4. Tighten DMARC to quarantine or reject once DKIM coverage is 100%.
5. (Optional) Switch SPF to -all only if you’re absolutely certain no valid mail will break alignment.

7. When -all Still Makes Sense

For domains that should never send email—such as parked domains or inbound‑only mailboxes—a hard‑fail SPF aligned with a DMARC p=reject policy is appropriate. But for active sending domains, soft‑fail maximises deliverability without compromising DMARC‑backed security.

Conclusion

SPF hard‑fail is a relic from a pre‑DMARC era. Today, with DMARC and DKIM doing the heavy lifting, soft‑fail (~all) gives you the best of both worlds: visibility into unauthorised flows, robust protection against spoofing, and minimal risk of blocking legitimate mail. Start soft, monitor closely, then only tighten when you’ve seen every source through the lens of DKIM and DMARC.

Navigating the Challenges of Using Distribution Lists with DMARC Enforcement

When managing email infrastructure, ensuring secure and reliable communication is paramount—especially for system administrators, systems engineers, and tech support professionals. One common challenge arises when distribution lists in Exchange are used to forward emails to external recipients, particularly when the original sender’s domain enforces strict DMARC policies. In this post, we dive into the technical challenges and practical solutions to keep your email deliverability on track.

---

The Technical Landscape

DMARC, SPF, and DKIM: The Basics

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) by ensuring that the authenticated domain in the "From:" header aligns with the sender’s policy. For organizations with strict DMARC settings (using policies like reject or quarantine), even small misalignments can result in legitimate emails being blocked or marked as spam.

Distribution Lists in Exchange

Distribution lists simplify communication by allowing you to send one email to multiple recipients. While they work flawlessly within internal networks, issues arise when:

• Recipients are External: Emails forwarded to addresses outside your domain.

• Sender's Domain Enforces DMARC: The original sender’s email is preserved during forwarding, causing potential DMARC failures if the forwarding server isn't authorized in the SPF records.

When the email’s envelope remains unchanged after forwarding, the external server may reject the message if the SPF and DKIM checks don’t pass DMARC validation.

---

Key Challenges

DMARC Alignment Failures

When forwarding via a distribution list, the original sender’s "From:" header is maintained, yet the Exchange server’s IP isn’t typically listed in the sender’s SPF records. Without adjustments, this misalignment can trigger SPF failures—and if DKIM is also compromised during the forwarding process, the entire DMARC validation fails.

Impact on Email Deliverability

Strict DMARC policies mean that even legitimate emails can be blocked or quarantined. This disrupts business communications and can hurt the sender's reputation if valid emails never reach their external recipients.

Complex Authentication Chains

Forwarding complicates the authentication process because the original sender’s credentials remain intact, while the message is transmitted via a server that isn’t part of the sender’s authorized network. This leads to a breakdown in the trust chain that DMARC relies on.

---

Mitigation Strategies

1. Address Alteration

One effective strategy is to alter the sender’s address during the forwarding process. By rewriting the sender’s address to a domain that is DMARC-compliant (typically the forwarding domain), you ensure that SPF records align and reduce the likelihood of DMARC failure.

Implementation Tips:

• Configure the Exchange server or distribution list to update the envelope sender.

• Use email routing rules to replace the “From:” or envelope sender with an authorized address.

2. Sender Rewriting Scheme (SRS)

SRS is designed to tackle DMARC issues in forwarding scenarios. It rewrites the envelope sender address so that the email appears to originate from a domain authorized to send emails on behalf of the forwarder.

Benefits of SRS:

• Maintains SPF Alignment: Rewrites the sender address to match the forwarder’s SPF records.

• Transparency: Allows traceability back to the original sender, even with the rewritten address.

• Seamless Integration: Can be incorporated into existing Exchange environments with the right configuration.

3. Combined Approaches

In some instances, a hybrid approach using both address alteration and SRS may offer the best results. While SRS tackles the SPF alignment issue, additional measures such as re-signing the email with DKIM on the forwarding server can further secure the forwarded email.

---

Best Practices for Email Delivery Professionals

• Regular DMARC Policy Reviews:
  Avoid overly strict DMARC policies on emails that might be legitimately forwarded. Consider starting with a “quarantine” policy to monitor impact before moving to “reject.”

• Monitor with DMARC Reporting Tools:
  Leverage DMARC reports to track authentication failures. This data is invaluable for refining forwarding rules and determining if further adjustments are needed.

• Test Before Deployment:
  Always validate configuration changes (address alteration, SRS implementation) in a test environment to ensure smooth delivery to external recipients.

• Stakeholder Education:
  Ensure that IT, security teams, and support staff understand these changes. Proper documentation and training can help streamline the transition and reduce confusion.

---

Conclusion

For professionals managing email delivery, particularly in environments with strict DMARC enforcement, forwarding emails via distribution lists in Exchange can present unique challenges. The crux of the issue lies in preserving the original sender’s details while satisfying DMARC requirements. By employing strategies like address alteration and SRS, you can maintain SPF alignment and safeguard your email communications. These solutions not only enhance deliverability but also ensure robust email security—critical for today’s dynamic email landscape.

Stay tuned for more insights on email delivery, and happy mailing from all of us at Delivery Depot!

DMARC Reports: Debunking Privacy Myths and Minimizing Risk

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an essential email authentication protocol designed to protect your domain from being used in phishing and spoofing attacks. 

One of DMARC’s core features is its ability to generate reports that provide valuable insights into who is sending emails on behalf of your domain. However, some organizations are hesitant to enable DMARC reporting due to concerns about sharing potentially sensitive data with third parties. This article aims to dispel misconceptions about DMARC reporting, clarify what information is actually shared, and provide practical guidance on how to minimize privacy risks.

Understanding DMARC Reports

DMARC generates two types of reports:

1. Aggregate Reports (RUA) - These reports provide a high-level overview of email authentication results, including metadata such as sending IP addresses, domain alignment, and the DMARC policy applied. They are sent to the address specified in the "rua" tag of your DMARC record.
2. Forensic Reports (RUF) - These reports, also known as failure or message-specific reports, contain more detailed information, including message headers, and in some cases, subject lines and content. They are sent to the address specified in the "ruf" tag.

Who Generates the Reports?

A common misconception is that sending DMARC reports involves your email server transmitting data to third parties. In reality, it is the receiving email server that generates these reports. When your domain sends an email to another server (like Gmail or Outlook), that server checks your DMARC policy and, if configured, generates a report based on the result of that check. Therefore, your organization has no control over whether a receiving server generates these reports once your policy requests them.

Aggregate vs. Forensic Reports

While both report types serve to increase visibility into your domain’s email traffic, they differ significantly in terms of privacy implications:

Aggregate Reports (RUA)

• Generated regardless of DMARC outcome (pass or fail).
• Contain only metadata and no email content, making them relatively safe from a privacy perspective.
• Typically sent daily and in XML format.

Forensic Reports (RUF)

• Generated only when a message fails DMARC checks.
• May include potentially sensitive information, such as message headers and even parts of the email body.
• Not all receiving servers generate forensic reports—many have opted not to, due to privacy and compliance concerns.
• The default behavior is to generate forensic reports only on DMARC failures.

Minimizing Privacy Risks

The best way to mitigate privacy risks is to limit which reports you request in your DMARC policy:

1. Exclude Forensic Reports (RUF) - Simply omit the "ruf" tag from your DMARC record to ensure no forensic data is collected or shared.

   Example DMARC record without RUF:

   v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com
   

2. Use Trusted Email Reporting Services - If you do use RUF, consider configuring it to send to a trusted third party or internal system that is designed to securely manage sensitive data.

3. Review Privacy Policies of Receiving Servers - Understand that the vast majority of servers do not generate forensic reports at all, and those that do typically redact or minimize content to protect privacy.

Final Thoughts

For organizations new to DMARC, the potential risks around RUF reports can seem daunting. However, the reality is that the vast majority of DMARC data shared is aggregate metadata that poses little to no risk of exposing sensitive content. By configuring your DMARC record carefully and opting only for RUA reports, you can significantly minimize your privacy exposure while still gaining valuable insights into email authentication.

Have questions or need more guidance on implementing DMARC? Reach out to a trusted expert to ensure your email domain is protected while maintaining privacy best practices.

Understanding the Public Suffix List: The Unsung Hero of Domain Management

The Public Suffix List (PSL) is one of those critical internet infrastructures that works silently in the background, yet few understand its purpose or importance. For those working in web development, security, or domain management, understanding the PSL can provide valuable insights into how browsers, email clients, and other applications make critical security decisions. This article explores the origins, purpose, and practical implications of this essential internet resource.

The Origins: When the DNS Hierarchy Got Complicated

In the early days of the internet, the domain name system was relatively simple. You had a handful of top-level domains (TLDs) like .com, .org, and .net, and organizations would register their domains directly under these TLDs. The boundary between the registrable part of a domain and its TLD was clear.

However, as the internet expanded globally, country-code TLDs (ccTLDs) emerged with their own registration policies. Some countries, like the UK (.uk) and Australia (.au), adopted a second-level hierarchy where organizations typically registered domains at the third level (e.g., example.co.uk or example.com.au). Suddenly, the clear boundary between registrable domains and "public" suffixes became blurred.

This ambiguity created a significant problem: how could software determine where the organizational boundary of a domain lies? Without this knowledge, critical security features like cookie handling could become vulnerable.

The Problem: Cookie Management and Security

The most pressing issue that led to the creation of the PSL was cookie security. Consider a site like example.com that sets a cookie. Browsers needed to prevent sites like malicious.example.com from accessing that cookie, as they are different organizational entities. However, in cases like example.co.uk and malicious.co.uk, both domains should be treated as distinct organizations despite sharing more domain components.

Without a standardized way to determine these boundaries, browsers had to rely on simplistic rules (like allowing cookies to be shared across subdomains) that created security vulnerabilities. In countries with multi-level TLDs, this problem was even more acute.

Mozilla's Solution: The Public Suffix List

In 2007, Mozilla recognized this problem and created the Public Suffix List—a community-maintained list of "public suffixes." A public suffix is essentially a domain under which internet users can directly register names. The PSL helps software distinguish between public suffixes and private domains.

For example, the PSL indicates that:

• .com is a public suffix
• .co.uk is a public suffix
• .github.io is a public suffix
• example.com is not a public suffix (it's an organisation level domain under .com)

What TLD+N Actually Means

To understand the PSL's impact, it helps to understand domain hierarchy terminology:

• TLD: The Top-Level Domain (e.g., .com, .org)
• TLD+1 (or eTLD+1): The TLD plus one level, which represents the "effective" registrable domain (e.g., example.com) - sometimes referred to as organisation level domain.
• TLD+2: The registrable domain plus one level, typically a subdomain (e.g., blog.example.com)

What makes this complex is that the "effective" TLD (eTLD) might include multiple parts. For instance:

• In example.com, the eTLD is .com
• In example.co.uk, the eTLD is .co.uk
• In example.github.io, the eTLD is .github.io

The PSL helps determine what counts as the effective TLD in any given domain.

PSL Additions and Removals: What They Mean

When a domain is added to the PSL:

• It becomes treated as a public suffix
• Subdomains immediately under it are considered separate registrable domains
• Cookies set by one subdomain can't be accessed by another subdomain
• SSL certificates must be issued separately for each subdomain
• Email sender policies may be evaluated differently

For example, when github.io was added to the PSL, alice.github.io and bob.github.io became treated as separate security contexts, just like alice.com and bob.com would be.

When a domain is removed from the PSL:

• It's no longer treated as a public suffix
• Subdomains are considered part of the same security context
• Cookies may be shared across previously separated domains
• Wildcard SSL certificates might cover more subdomains
• Security policies may need reconfiguration

Who Maintains the PSL?

The PSL was originally created by Mozilla and is still primarily maintained by them, though it has become a community effort. The list itself is hosted as an open-source project on GitHub (https://github.com/publicsuffix/list).

Mozilla remains the steward of the project, but contributions come from a wide range of organizations and individuals with interests in domain policy and web security.

The Approval Process

The process for adding or removing domains from the PSL involves:

1. Submission: Creating a pull request on GitHub with the proposed change
2. Justification: Providing evidence that the domain operates as a public suffix where third parties can register domains
3. Review: Community and maintainer assessment of the request
4. Implementation: Merging the change if approved
5. Distribution: Updates are periodically released and adopted by consuming applications

For a domain to be added, it typically needs to demonstrate that:

• It allows third-party domain registration (or subdomain allocation)
• Different entities control different subdomains
• There's a legitimate need for security isolation between subdomains

The review process focuses on preventing abuse, as being in the PSL can confer certain advantages (particularly for cookie access and storage quotas).

Applications and Protocols Relying on PSL

The PSL has become a critical component for numerous systems:

Browsers:

• Cookie management (the original use case)
• Local storage limitations
• Security origin determination
• HSTS (HTTP Strict Transport Security) propagation

Certificate Authorities:

• Validation of domain control
• Issuance policies for wildcard certificates
• Name constraints enforcement

Email Systems:

• DMARC and SPF policy evaluation
• Determining organizational boundaries for anti-spoofing
• Email authentication alignment checks

Security Tools:

• Same-origin policy enforcement
• Cross-origin resource sharing (CORS) decisions
• Content Security Policy (CSP) implementation

Web Frameworks:

• Domain validation
• Routing decisions
• Security headers configuration

The degree of reliance varies, but cookie security remains the most critical application. Some systems implement their own version or modification of the PSL, creating occasional inconsistencies between applications.

Tools for Working with the Public Suffix List

For those looking to integrate PSL functionality into their own applications, several tools and APIs are available. One particularly useful resource is the publicsuffixlist-api project on GitHub. 

This open-source API provides a convenient way to query and interact with the Public Suffix List programmatically, making it easier to implement PSL-based domain validation and security features in your own applications. The API offers simple endpoints for checking domain status, determining effective TLDs, and validating domain structures—all while staying synchronized with the official PSL. 

For developers working on domain management tools, security applications, or web frameworks, this API can significantly simplify the process of correctly implementing PSL-based logic without having to maintain your own parsing and update mechanisms.

Implementation Challenges

Despite its importance, PSL integration isn't perfect:

• Applications may use outdated versions of the list
• Some implementations have bugs or misinterpretations
• The list requires regular updates as the domain landscape changes
• Edge cases exist that the PSL doesn't fully address

Conclusion

The Public Suffix List represents a community solution to a complex problem in internet infrastructure. While invisible to most users, it plays a crucial role in maintaining security boundaries online. For technical professionals working with domains, understanding the PSL provides valuable context for security decisions, application development, and domain strategy.

As the web continues to evolve, the PSL remains a living document that adapts to new domain structures and registration policies. Being aware of its existence and function is increasingly important for anyone working with web technologies at an intermediate to advanced level.

Bridging the Gap: Enforcing TLS 1.3 for Legacy On-Premises Devices in Email Delivery

In the world of email delivery, security is paramount. As protocols and standards evolve, staying up-to-date with the latest encryption methods is essential to protect sensitive information. TLS 1.3, the latest version of the Transport Layer Security protocol, provides enhanced security and performance compared to its predecessors. However, not all systems are ready to make the leap, especially legacy on-premises devices that only support plaintext or outdated protocols like TLS 1.1.

This creates a dilemma for businesses: How do you ensure secure email delivery while maintaining compatibility with older devices? In this article, we’ll explore the problem, propose a solution, and provide a configuration guide for stunnel, a tool that can bridge the gap between legacy devices and modern, secure communication.

The Problem: Legacy Devices and Modern Security Standards

Many organizations rely on older devices that lack support for modern encryption standards. These devices may only support:

• Plaintext communication, which is highly insecure and vulnerable to interception.
• Outdated encryption protocols like TLS 1.1, which are no longer considered safe.

At the same time, email relay services like Mimecast require secure communication, with a preference for TLS 1.2 or TLS 1.3. This creates a compatibility issue: legacy devices are unable to connect securely to email smarthosts without additional intervention.

The Solution: Stunnel as a Secure Proxy

To solve this problem, we can use stunnel, a lightweight tool designed to act as a secure proxy. Stunnel allows us to:

1. Accept plaintext or older TLS connections locally from legacy devices.
2. Securely encrypt and enforce TLS 1.3 for outgoing connections to Mimecast.

This approach ensures that even older devices can continue to function while protecting your data during email delivery over the internet. Below, we’ll walk you through a step-by-step guide to configure stunnel for this purpose.

Step-by-Step Configuration

Here’s how to configure stunnel to accept plaintext connections locally and enforce TLS 1.3 when sending emails to Mimecast’s outbound SMTP servers (xx-smtp-outbound-1.mimecast.com and xx-smtp-outbound-2.mimecast.com).

1. Install Stunnel

First, install stunnel on your server. On a Linux-based system, you can install it using the following commands:

sudo apt update
sudo apt install stunnel4

2. Generate a Stunnel Certificate

Stunnel requires a certificate for secure communication. You can generate a self-signed certificate by running:

openssl req -new -x509 -days 365 -nodes -out stunnel.pem -keyout stunnel.pem
chmod 600 stunnel.pem

Move the stunnel.pem file to a secure location, such as /etc/stunnel/.

3. Configure Stunnel

Create a configuration file for stunnel. Name it stunnel.conf and place it in /etc/stunnel/. Here’s an example configuration tailored for Mimecast:

# Stunnel Configuration

# Use the generated certificate
cert = /etc/stunnel/stunnel.pem

# Enforce TLS 1.3 for outgoing connections
sslVersion = TLSv1.3

# Debugging (set to 5 for detailed logs during troubleshooting)
debug = 3
output = /var/log/stunnel.log

# Service 1: Connect to Mimecast's primary SMTP server
[xx-smtp-outbound-1]
client = yes
accept = 127.0.0.1:2525  # Local port for plaintext connections
connect = xx-smtp-outbound-1.mimecast.com:587

# Service 2: Connect to Mimecast's secondary SMTP server
[xx-smtp-outbound-2]
client = yes
accept = 127.0.0.1:2526  # Local port for plaintext connections
connect = xx-smtp-outbound-2.mimecast.com:587

4. Start Stunnel

Enable and start the stunnel service:

sudo systemctl enable stunnel4
sudo systemctl start stunnel4

To verify that stunnel is running and listening on the specified ports (2525 and 2526), use the following command:

sudo netstat -tuln | grep stunnel

5. Update Your Devices

Configure your legacy on-premises devices to send emails to 127.0.0.1 on ports 2525 (for the primary server) or 2526 (for the secondary server). These local connections will be forwarded by stunnel to Mimecast with TLS 1.3 encryption.

6. Test the Configuration

To ensure everything is working as expected, you can test the local connection using telnet:

telnet 127.0.0.1 2525

Once connected, send a test email through your legacy device or email client configured to use the stunnel proxy. Verify that the email is successfully delivered.

Why Choose Stunnel?

Using stunnel provides several key benefits:

• Compatibility: Legacy devices can continue to use plaintext or older TLS protocols without modification.
• Security: Outgoing connections to Mimecast are encrypted with TLS 1.3, ensuring compliance with modern security standards.
• Simplicity: Stunnel is lightweight, easy to configure, and doesn’t require significant changes to your infrastructure.

Final Thoughts

In today’s cybersecurity landscape, it’s critical to balance compatibility with legacy systems and modern security requirements. Tools like stunnel provide an elegant solution, enabling you to secure your email delivery while accommodating older devices.

By following the steps outlined in this article, you can enforce TLS 1.3 for your email delivery via Mimecast, ensuring both security and compliance. If you have any questions or run into challenges with this setup, feel free to leave a comment below or reach out—we’re here to help!

Let’s keep email delivery secure, reliable, and future-proof.

Strengthening Email Security: Understanding SMTP-DANE and DNSSEC

In today’s digital world, email remains a primary business communication tool, but it’s also one of the biggest targets for cyber threats. As email-based attacks become more sophisticated, organizations need to adopt security measures that protect communications from interception and impersonation. Two critical technologies that enhance email security are DNSSEC (Domain Name System Security Extensions) and SMTP-DANE (DNS-based Authentication of Named Entities for SMTP).

While these terms may sound technical, understanding them is key to explaining their value to customers. This guide will break them down in a clear and practical way.

---

What is DNSSEC?

The Domain Name System (DNS) acts as the internet’s phonebook, translating human-friendly domain names like example.com into numerical IP addresses. However, traditional DNS lacks built-in security, making it vulnerable to threats like DNS spoofing, which can redirect users to fraudulent websites.

DNSSEC (Domain Name System Security Extensions) was developed to prevent these attacks. It verifies the authenticity and integrity of DNS records by using digital signatures, ensuring that when someone looks up a website or email server, they are getting the real, untampered result.

Key Business Benefit: Prevents cybercriminals from manipulating DNS records to launch phishing attacks or intercept communications.

---

What is SMTP-DANE?

While DNSSEC secures domain lookups, SMTP-DANE (DNS-based Authentication of Named Entities for SMTP) builds on this security to protect email communication. It ensures that emails are delivered securely to the intended recipient’s mail server, reducing the risk of interception.

The Problem SMTP-DANE Solves

Most email servers rely on STARTTLS, a protocol designed to encrypt emails during transit. However, this system has a major weakness: it does not verify the authenticity of encryption certificates. Attackers can exploit this gap through downgrade attacks or man-in-the-middle attacks, where they strip away encryption and intercept sensitive emails.

How SMTP-DANE Works

SMTP-DANE solves this problem by using TLSA records stored in DNSSEC-protected DNS entries. These records verify the legitimacy of a recipient’s email server certificate before sending an email, ensuring it is delivered securely.

Key Business Benefit: Prevents cybercriminals from intercepting or tampering with email communication by ensuring encryption certificates are legitimate and enforced.

---

Why DNSSEC and SMTP-DANE Work Together

While DNSSEC and SMTP-DANE serve different functions, they are complementary:

• DNSSEC secures the DNS system, preventing attackers from manipulating DNS records.
• SMTP-DANE secures email transport, ensuring encryption certificates cannot be faked or bypassed.

SMTP-DANE cannot function without DNSSEC, making them a critical pair for businesses that want to secure both web traffic and email communication.

---

Why Businesses Should Care About SMTP-DANE

Adopting SMTP-DANE isn’t just about technical security—it has direct business benefits that resonate with sales teams and customers alike:

1. Protects Business Reputation
   Prevents email spoofing and impersonation, reducing the risk of phishing attacks that can damage brand trust.

2. Strengthens Customer Relationships
   Ensures customers receive genuine, secure emails from your business, reducing the risk of fraud and increasing confidence in communications.

3. Enhances Compliance Readiness
   Many industries, including finance and healthcare, have strict security requirements. SMTP-DANE helps businesses align with evolving regulations.

4. Reduces Cybersecurity Risks
   Lowers the risk of email interception, protecting sensitive business and customer data from prying eyes.

5. Future-Proofs Email Security
   As cyber threats evolve, businesses that implement SMTP-DANE position themselves ahead of security challenges.

---

Industries & Regions Leading Adoption

Certain industries and regions have been early adopters of DNSSEC and SMTP-DANE due to their heightened security needs:

Industries Benefiting the Most:

• Financial Services: Protects customer transactions and prevents banking fraud.
• Healthcare: Safeguards sensitive patient data and ensures compliance with regulations like GDPR and HIPAA.
• E-Commerce: Secures customer information, preventing email-based fraud.
• Government & Defence: Protects classified communication from cyber threats.

Regions Leading the Way:

• APAC (Asia-Pacific): Countries like Australia and Singapore have been strengthening cybersecurity regulations, making technologies like SMTP-DANE increasingly relevant.
• Europe: Driven by GDPR and strict data protection laws, many organizations have already adopted DNSSEC and SMTP-DANE.
• United States: The U.S. government mandates DNSSEC for federal domains, pushing adoption in both the public and private sectors.

---

Final Thoughts

Email security is no longer just a technical concern—it’s a business necessity. SMTP-DANE, backed by DNSSEC, ensures that organizations can confidently send and receive emails without fear of interception or impersonation.

For sales professionals, understanding these technologies provides a valuable differentiator when discussing security solutions with customers. By framing the conversation around trust, brand protection, and compliance, businesses can see SMTP-DANE not as an optional upgrade, but as an essential tool in today’s threat landscape.

DNS Authentication: The Key to Landing Messages in the Inbox

When it comes to email marketing, reaching your audience’s inbox is the first critical step. Yet, with increasing email security measures and stricter spam filters, getting your messages to land where they belong is no small feat. One of the most vital components in ensuring deliverability is DNS authentication. In this article, we’ll explore why DNS authentication is crucial, delve into best practices for opt-in marketing, and underscore the importance of an easy opt-out process.

What is DNS Authentication?

DNS (Domain Name System) authentication is a set of protocols that verifies the legitimacy of an email sender. It protects against spoofing, phishing, and unauthorized use of your domain by ensuring that only authorized parties can send emails on behalf of your domain. The primary protocols involved are:

1. SPF (Sender Policy Framework): Specifies which mail servers are authorized to send emails for your domain.

2. DKIM (DomainKeys Identified Mail): Uses cryptographic signatures to verify that an email has not been tampered with during transit and is genuinely from the claimed sender.

3. DMARC (Domain-based Message Authentication, Reporting, and Conformance): Builds on SPF and DKIM to instruct receiving servers on how to handle unauthorized messages. It also provides visibility into unauthorized use through reporting.

4. BIMI (Brand Indicators for Message Identification): While not a security protocol, BIMI complements authentication by displaying your brand logo in recipients' inboxes, boosting trust and recognition.

Why DNS Authentication Matters for Deliverability

Without proper DNS authentication, email providers like Gmail, Microsoft 365, and Yahoo are more likely to flag your messages as spam or outright reject them. Here’s why it matters:

• Reputation Protection: Authentication helps build and maintain your domain’s reputation, a key factor in deliverability.
• Recipient Trust: Authenticated emails are less likely to trigger suspicion, fostering trust among recipients.
• Compliance with Security Standards: DNS authentication aligns your practices with industry standards, avoiding penalties or deliverability issues.

Best Practices for DNS Authentication

To maximize the effectiveness of your DNS authentication setup, follow these best practices:

1. Publish Accurate SPF Records: Ensure your SPF record includes all mail servers you use to send email. Use a single SPF record per domain to avoid conflicts.

2. Implement DKIM Signing: Generate a DKIM key pair and publish the public key in your DNS. Sign all outgoing emails with the private key.

3. Enforce DMARC Policies: Start with a relaxed policy (p=none) to monitor email traffic, then move to stricter policies (p=quarantine or p=reject) as you gain confidence.

4. Monitor with DMARC Reports: Regularly review DMARC reports to identify unauthorized use of your domain and troubleshoot misconfigurations.

5. Consider BIMI: If your authentication is robust, implement BIMI to enhance your brand visibility and reinforce legitimacy.

Opt-In Marketing: Building a Compliant and Engaged Audience

Even with perfect DNS authentication, engaging in poor email marketing practices can still land your emails in the spam folder. Adhering to industry standards for opt-in marketing ensures a receptive audience and preserves your domain’s reputation.

• Double Opt-In: Require recipients to confirm their subscription via email to ensure their consent.
• Clear Consent: Clearly explain what type of emails subscribers will receive when they sign up.
• No Purchased Lists: Avoid using purchased or scraped email lists, which often include invalid or uninterested recipients.
• Segment Your Audience: Tailor your emails to specific audience segments for better engagement and fewer spam complaints.

The Importance of Easy Unsubscribing

A seamless opt-out process is not just good practice; it’s a legal requirement in many regions, including under GDPR, CAN-SPAM, and Australia’s Spam Act.

• Prominent Unsubscribe Links: Include a clearly visible and easy-to-use unsubscribe link in every email.
• Immediate Processing: Honour unsubscribe requests promptly, typically within 24-48 hours.
• Feedback Options: Provide an optional feedback form to understand why recipients are unsubscribing.

Conclusion

DNS authentication is the backbone of reliable email deliverability, ensuring your messages are trusted and received by your audience. Coupled with best practices in opt-in marketing and a user-friendly unsubscribe process, you’ll not only reach the inbox but also foster lasting relationships with your audience. By investing in these strategies, your email campaigns will achieve greater engagement and credibility—essential ingredients for success in today’s digital landscape.

The Importance of DMARC for Australian Organisations: Business Benefits and Requirements

In an era where email remains the primary communication channel for organisations, ensuring its security has never been more critical. Cybercriminals increasingly exploit email to launch phishing attacks, impersonate businesses, and steal sensitive information. For Australian organisations, deploying DMARC (Domain-based Message Authentication, Reporting, and Conformance) is essential not only for cybersecurity but also for maintaining business continuity, reputation, and regulatory compliance.

Understanding DMARC

DMARC is an email authentication protocol that helps organisations protect their domains from being used in malicious activities such as phishing and spoofing. It works by aligning SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) records with the organisation's email domain and provides domain owners with control over how unauthenticated messages are handled.

Business Benefits of DMARC for Australian Organisations

1. Protecting Brand Reputation

   Brand trust is paramount for Australian businesses, especially in industries like finance, healthcare, and e-commerce, where customer data and transactions are critical. A compromised email domain can lead to customers receiving fraudulent emails, damaging trust and harming the organisation's reputation.

   DMARC helps prevent domain spoofing, ensuring that only legitimate emails reach customers and stakeholders.

2. Improving Email Deliverability

   A properly configured DMARC policy enhances email deliverability by verifying the authenticity of emails sent from your domain. Internet Service Providers (ISPs) are more likely to deliver authenticated emails to the inbox rather than flagging them as spam or rejecting them outright.

   For Australian businesses engaged in global trade, improved deliverability ensures seamless communication with partners and customers worldwide.

3. Reducing Cybersecurity Risks

   DMARC mitigates phishing attacks by blocking unauthorised use of your domain in emails. This reduces the likelihood of financial losses, legal implications, and data breaches caused by successful phishing campaigns targeting employees or customers.

4. Insights Through Reporting

   DMARC provides detailed reports on email authentication activity. These reports allow organisations to:

   • Monitor who is sending emails on behalf of their domain.
   • Detect and respond to potential misuse in real-time.
   • Gain insights into their email ecosystem for optimisation.

5. Enhancing Regulatory Compliance

   Australia’s regulatory environment increasingly emphasises the need for robust cybersecurity measures. Adopting DMARC helps organisations align with requirements outlined in the Australian Privacy Act, Essential Eight Strategies to Mitigate Cybersecurity Incidents, and industry-specific standards such as APRA CPS 234 for financial institutions.

Business Requirements for DMARC Implementation

1. Setting Up SPF and DKIM

   DMARC requires a foundation of SPF and DKIM configurations. Australian organisations should:

   • Publish SPF records to specify authorised email servers.
   • Implement DKIM to add a cryptographic signature to emails for integrity verification.

2. Publishing a DMARC Record

   A DMARC record is a DNS TXT entry that specifies the organisation's policy for handling unauthenticated emails (none, quarantine, or reject). Initially, a policy of “none” allows organisations to monitor email traffic without impacting delivery.

3. Analysing DMARC Reports

   Analysing aggregate and forensic reports is vital for understanding domain activity and detecting potential abuse. Using DMARC analysis tools can streamline this process and provide actionable insights.

4. Moving to Enforcement

   Once confident in the authentication configurations, organisations should move to stricter DMARC policies (“quarantine” or “reject”) to actively block unauthenticated emails.

5. Ongoing Maintenance

   Maintaining DMARC involves regular monitoring, updating SPF and DKIM records as necessary, and ensuring new email systems or vendors align with DMARC policies.

Conclusion

For Australian organisations, DMARC is more than a technical safeguard; it is a business enabler that fosters trust, improves communication reliability, and safeguards against growing cyber threats. By implementing DMARC, businesses can not only protect their brand and customers but also meet regulatory obligations and strengthen their position in an increasingly competitive market.

The benefits of DMARC—from enhanced deliverability to reduced cyber risks—make it a must-have in any organisation’s cybersecurity strategy. As email threats evolve, DMARC provides Australian businesses with a robust framework to secure their communications and build lasting trust with stakeholders.

Understanding Email Deliverability and the Dangers of SPF Misconfigurations: Lessons from the MikroTik Botnet Attack

Email deliverability is a cornerstone of successful communication in today’s digital world. However, its effectiveness hinges on properly configured email authentication protocols, such as the Sender Policy Framework (SPF). Missteps in SPF configurations can open the floodgates for abuse, as highlighted in the recent MikroTik botnet attack, which exploited misconfigured SPF DNS records to propagate malware. This post unpacks the implications of SPF misconfigurations, particularly the peril of using +all in SPF records, and draws parallels to this alarming incident.

---

SPF and the Role It Plays in Email Authentication

SPF is a DNS-based email authentication protocol that helps domain owners specify which mail servers are authorized to send emails on their behalf. By publishing an SPF record in their domain’s DNS settings, administrators create a list of permitted IP addresses. When an email is received, the recipient's mail server checks the sender's IP against this list. Based on the SPF evaluation (Pass, Fail, Neutral, or SoftFail), the server determines whether the email is legitimate.

A correctly configured SPF record strengthens a domain’s email reputation, minimizes spam, and prevents spoofing. However, misconfigurations can have the opposite effect.

---

The MikroTik Botnet Incident: A Case Study

A recent report from BleepingComputer revealed how attackers exploited misconfigured SPF records to spread malware. The botnet, powered by compromised MikroTik routers, sent phishing emails with malicious attachments. The attackers abused improperly configured SPF records, which either lacked strict enforcement or explicitly allowed all servers to send on behalf of a domain.

This misconfiguration enabled malicious actors to impersonate legitimate domains, bypassing email security checks and delivering their payloads to unsuspecting victims. Once recipients opened the attachments, their systems were infected, and the botnet grew larger, perpetuating a vicious cycle.

---

The Danger of +all in SPF Records

At the heart of the SPF misconfiguration issue lies the improper use of +all. In an SPF record, +all effectively authorizes any mail server to send emails on behalf of the domain. This is akin to leaving the door wide open and inviting both legitimate and malicious traffic.

For example, consider this SPF record:

v=spf1 +all

This configuration tells receiving mail servers that all IP addresses are allowed to send emails for the domain. While this approach eliminates deliverability issues caused by overly restrictive policies, it undermines the very purpose of SPF, leaving the domain vulnerable to abuse.

Instead, administrators should use restrictive mechanisms like -all (fail) or ~all (soft fail) to enforce stricter authentication:

• -all: Emails from unauthorized servers are rejected outright.
• ~all: Emails from unauthorized servers are marked as suspicious but may still be delivered.

---

Lessons Learned and Best Practices

1. Audit Your SPF Records Regularly
   Review SPF configurations to ensure only trusted IP addresses and mail servers are listed. Avoid using +all or overly permissive settings.

2. Implement Complementary Email Authentication Protocols
   While SPF is crucial, it should be combined with other protocols like DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) for a layered defense.

3. Monitor for Abnormal Email Activity
   Use monitoring tools to detect spikes in email traffic or unusual patterns that could indicate a compromise.

4. Secure Network Infrastructure
   The MikroTik incident underscores the importance of securing routers and other network devices to prevent them from being hijacked for malicious purposes.

5. Educate End-Users
   Train employees and users to recognize phishing emails and avoid interacting with suspicious attachments or links.

---

Conclusion

The MikroTik botnet attack serves as a cautionary tale about the consequences of SPF misconfigurations, particularly the misuse of +all. Properly configuring SPF records, combined with a comprehensive email authentication strategy, is critical to safeguarding email deliverability and protecting against abuse. Organizations must remain vigilant, regularly audit their email infrastructure, and adopt robust cybersecurity practices to ensure that their communication channels remain secure and trustworthy.

The Importance of High Availability for Postfix in Large On-Premises Email Relays

In environments with high email traffic, such as universities, ensuring high availability (HA) for email relay infrastructure is paramount. Reliable email delivery impacts communication, operations, and the academic experience. Open-source tools like Postfix, combined with modern load balancing and failover solutions, can provide a robust, scalable email relay system. This article explores how Postfix can be configured for HA in such scenarios, using Debian as the base operating system.

Understanding High Availability in Email Relays

High availability ensures continuous operation of email relay services even during server failures or maintenance. For universities, where thousands of emails are sent daily from various departments, research groups, and administrative offices, disruptions in email flow can lead to significant operational challenges. Configuring Postfix in an HA setup ensures:

1. Redundancy: Eliminating single points of failure.
2. Load Balancing: Distributing email traffic evenly across multiple Mail Transfer Agents (MTAs).
3. Failover: Seamless transition during server downtimes or network issues.

Setting Up Multiple MTAs with Postfix on Debian

Postfix, known for its flexibility and performance, is an ideal choice for handling unauthenticated email relay within a university’s internal network. Here’s how you can set up multiple MTAs:

1. Install Postfix on Debian:

   apt update && apt install postfix
   

   Configure Postfix to operate as a relay host during installation.

2. Restrict Access to LAN IPs: In the Postfix configuration file /etc/postfix/main.cf, restrict relay permissions to LAN IPs:

   mynetworks = 192.168.0.0/16 [::1]/128
   relay_domains = *
   smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination
   

3. Enforce TLS 1.3 to Smarthosts: Configure Postfix to communicate with smarthosts over TLS 1.3:

   smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1, TLSv1.2, TLSv1.3
   smtp_tls_security_level = encrypt
   smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
   

4. Reverse DNS Setup: Ensure all university IPs have reverse DNS entries pointing to meaningful hostnames to avoid being flagged as spam.

5. DKIM Signing and SPF Records:

   • Use smarthosts to apply DKIM signatures to outgoing emails.
   • Ensure the smarthost IPs are listed in the university domain’s SPF record.

     v=spf1 ip4:203.0.113.0/24 -all
     

Load Balancing with HAProxy

To distribute traffic among multiple MTAs, HAProxy acts as a load balancer:

1. Install HAProxy:

   apt install haproxy
   

2. Configure HAProxy: Create /etc/haproxy/haproxy.cfg:

   global
       log /dev/log local0
       maxconn 2000
   
   defaults
       log global
       option tcplog
       timeout connect 5000ms
       timeout client 50000ms
       timeout server 50000ms
   
   frontend smtp_frontend
       bind *:25
       mode tcp
       default_backend smtp_backend
   
   backend smtp_backend
       mode tcp
       balance roundrobin
       server mta1 192.168.1.2:25 check
       server mta2 192.168.1.3:25 check
       server mta3 192.168.1.4:25 check
   

   Restart HAProxy to apply the changes.

Adding Failover with Keepalived

Keepalived ensures continuous availability by managing virtual IPs with failover and failback capabilities.

1. Install Keepalived:

   apt install keepalived
   

2. Configure Keepalived: Create /etc/keepalived/keepalived.conf:

   vrrp_instance VI_1 {
       state MASTER
       interface eth0
       virtual_router_id 51
       priority 100
       advert_int 1
       authentication {
           auth_type PASS
           auth_pass secret
       }
       virtual_ipaddress {
           192.168.1.100
       }
   }
   

   Configure similar instances on other servers with adjusted state and priority values.

3. Restart Keepalived:

   systemctl restart keepalived
   

End-to-End Email Relay Workflow

1. Email Submission: Devices within the university LAN submit emails to the Postfix servers via HAProxy.

2. Relay and Encryption: Postfix enforces TLS 1.3 and relays the email to configured smarthosts.

3. DKIM Signing and SPF Validation: Smarthosts sign outgoing emails with DKIM, and their IPs align with the SPF records.

4. Recipient Delivery: The smarthosts send the emails to their final destinations.

Benefits of the Architecture

• Resilience: Redundant MTAs and load balancing minimize downtime.
• Security: TLS enforcement and compliance with email authentication protocols reduce the risk of spoofing and data breaches.
• Scalability: HAProxy and Keepalived allow seamless addition of MTAs to handle increased traffic.

By combining Postfix, HAProxy, and Keepalived, universities can build a high-performance, resilient email relay system that ensures reliable communication across campus.

Understanding DMARC: Protecting Your Domain with SPF, DKIM, and Alignment

Email security is a crucial element in ensuring that your communication remains trusted and your brand's reputation intact. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a powerful protocol that builds on two other essential email authentication methods: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). Together, they create a robust defense against email spoofing and phishing attacks. But how does DMARC work, and what is its relationship with SPF and DKIM?

Let’s break it down.

---

The Foundations: SPF and DKIM

SPF (Sender Policy Framework)

SPF is an email authentication method that allows domain owners to specify which mail servers are authorized to send emails on their behalf.

Here’s how SPF works:

1. The domain owner publishes an SPF record in their DNS.
2. When an email is sent, the receiving server checks the SPF record to ensure the sending server’s IP address matches what’s listed in the DNS.
3. If it matches, the SPF check passes; if not, it fails.

Example Scenario:
Imagine your domain, example.com, authorizes only Mail Server A to send emails. If someone tries to send an email from example.com using Mail Server B, the SPF check will fail, alerting the recipient that the email may not be legitimate.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to your email headers to verify that the message has not been altered in transit and that it originates from an authorized domain.

Here’s how DKIM works:

1. The domain owner generates a public-private key pair and publishes the public key in their DNS.
2. When sending an email, the mail server signs the email with the private key.
3. The receiving server retrieves the public key from DNS to validate the signature.

Example Scenario:
If an email’s signature matches the domain's public key, it confirms that the message is genuine and hasn’t been tampered with.

---

The Role of DMARC

While SPF and DKIM are effective on their own, they have a critical limitation: neither verifies whether the domain being authenticated aligns with the one visible to the email recipient (the “From” address). This gap allows bad actors to exploit unauthenticated subdomains or domains and impersonate trusted brands.

DMARC addresses this by introducing alignment and enforcing policies that dictate how email servers handle messages that fail SPF or DKIM checks.

Alignment: The Key to DMARC

Alignment ensures that the domain used to pass SPF or DKIM checks matches the domain in the "From" header of the email. There are two types of alignment:

1. SPF Alignment:

   • Strict Alignment: The domain in the SPF check (the MAIL FROM or Return-Path domain) must exactly match the domain in the "From" address.
   • Relaxed Alignment: The domains must share the same organizational domain (e.g., mail.example.com aligns with example.com).

2. DKIM Alignment:

   • Strict Alignment: The domain in the DKIM signature must exactly match the domain in the "From" address.
   • Relaxed Alignment: The domains must share the same organizational domain.

DMARC Policies

DMARC allows domain owners to specify what action receiving servers should take when a message fails authentication checks:

• None: No action is taken; used for monitoring.
• Quarantine: Messages failing authentication are sent to the spam/junk folder.
• Reject: Messages failing authentication are outright rejected.

---

Why SPF and DKIM Alone Aren’t Enough

Without DMARC, even if a message passes SPF or DKIM, it can still appear to come from an unauthorized sender because alignment isn’t enforced. For example:

• SPF Only: A malicious actor could send an email with a forged "From" address while using an authorized sending server listed in the SPF record.
• DKIM Only: The email could pass DKIM verification, but the domain in the DKIM signature might not align with the "From" address.

DMARC eliminates these vulnerabilities by requiring SPF or DKIM to pass and ensuring alignment.

---

The Prerequisites for Passing DMARC

To pass DMARC, a message must meet these conditions:

1. Pass SPF or DKIM checks (or both).
2. Achieve domain alignment with the "From" address for at least one method (SPF or DKIM).

Example:

• An email is sent from sales@example.com.
• SPF passes because the sending server is authorized in the SPF record for example.com.
• DKIM passes because the message is signed with a private key matching example.com.
• Alignment is achieved for both SPF and DKIM because the authenticated domains match the "From" address (example.com).

Result: The email passes DMARC.

---

Conclusion: Why DMARC Matters

DMARC is the glue that binds SPF and DKIM together, creating a comprehensive framework for email authentication. By enforcing alignment, DMARC ensures that only legitimate emails are delivered to recipients, protecting your domain from spoofing and phishing.

For businesses, implementing DMARC is not just about security—it’s about preserving trust and reputation in every email you send. By publishing a DMARC policy, monitoring results, and gradually moving from "none" to "quarantine" or "reject," you can build a robust email authentication strategy that stands the test of evolving threats.

Ready to protect your domain? Start by evaluating your SPF and DKIM setup, align them with your "From" address, and deploy DMARC with confidence. Your email deliverability—and your brand—will thank you.