Skip to main content

SecuraWall.com

Email security and continuity

Explore
Technical Guide · Microsoft 365 & Cloud

SPF, DKIM and DMARC for Exchange Online

SPF, DKIM and DMARC are complementary mechanisms that help authenticate mail sent for your domain and define policy for handling spoofed messages.

LAST TECHNICAL REVIEW:
Microsoft 365 & Cloud

Why This Topic Matters

SPF, DKIM and DMARC are complementary mechanisms that help authenticate mail sent for your domain and define policy for handling spoofed messages.

Key Decision Points

Reduce unnecessary SPF includes and senders.

Enable DKIM and verify keys regularly.

Start DMARC with reporting and tighten policy gradually.

Inventory third-party sending services.

Architecture and operating model

SPF declares which servers may send for the envelope-sender domain. DKIM signs selected headers and the body with a domain key. DMARC evaluates alignment between the visible From domain and the SPF or DKIM identity. SPF passing alone does not imply DMARC passing. A DNS record also does not prove that a real message follows the intended route.

Forwarding may break SPF; a preserved aligned DKIM signature may still satisfy DMARC in some flows. Intermediaries that alter messages can break DKIM too. Include CRM, newsletters, scanners and invoicing services in the sender inventory. Moving to reject before inspecting monitoring reports can block legitimate mail. TXT changes, key rotation and DNS propagation need controlled handling.

  1. 1Sender inventory
  2. 2SPF and DKIM identity
  3. 3Alignment with From
  4. 4DMARC result and report
Validate SPF, DKIM and DMARC separately in real message headers for every sending source.

Design parameters

Alignment
Compare visible From with SPF envelope identity and DKIM d=; SPF pass alone is insufficient.
DNS and sender inventory
Check one correct SPF record, lookup limits, DKIM selectors and external senders together.
Identity and tenant boundary
Separate user, guest, administrator and application identities. Tenant policies and individual-resource permissions differ in scope.
Data ownership and lifecycle
Define ownership, retention, deletion paths and recovery. Distinguish synchronization from backup.
Licensing and feature scope
Verify licensing against user role, device, tenant and required features. Do not assume current package names from historical information.
Connectivity and cost
Assess internet, identity, egress, storage and operating costs together. Do not assume a budget alert automatically stops spending.

Worked example

Assume the visible sender is company.example and the envelope sender is service.example. Even if SPF passes for service.example, it does not by itself satisfy DMARC because it is not aligned with company.example. Verify an aligned DKIM signature in the actual message’s Authentication-Results header. Collect reports, correct legitimate senders and tighten policy in stages.

Example commands: replace lab values and confirm permissions and software versions before use.

nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com

Troubleshooting

ObservationLikely cause / distinctionVerification
SPF passes but DMARC failsThe SPF domain may not align and DKIM may not qualify.Inspect identity, alignment and DKIM separately in real Authentication-Results headers.
Some users cannot accessLicensing, groups, device state or access policies may differ.Compare decision records for affected and successful users.
Deleted data cannot be recoveredRetention or recovery scope may differ from assumptions.Verify object type, deletion time and official recovery conditions.
Cost exceeds forecastResource size, egress, retention or commitment utilization may differ.Compare actual and forecast costs by resource and service.

Acceptance checks

  1. Validate SPF, DKIM and DMARC separately in real message headers for every sending source.
  2. Include every legitimate sending service in inventory and DNS design.
  3. Validate visible From alignment with SPF/DKIM identities in real messages.
  4. Check Authentication-Results on forwarded messages separately.
  5. Review DMARC reports and tighten policy in stages.
  6. Validate old/new selectors and DNS propagation during DKIM rotation.

Related concepts

DNS caching and dependencies

DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.

Authentication and sessions

Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.

Trust boundary and failure domain

A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.

Policy lifecycle

A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.

Telemetry and time correlation

Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.

Availability versus recovery

High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.

Primary documentation

SecuraWall MailFlow

Email Security and Continuity

Backup MX, SMTP Gateway, AntiSpam and Antivirus services.

Explore SecuraWall MailFlow
Who · How · Why

How This Content Was Prepared

WHO?

Doz Teknoloji Technical Team

This content is based on the technical evaluation approach used across Doz Teknoloji's enterprise IT practice areas.

HOW?

Technical criteria + primary sources

The topic was cross-checked against vendor documentation, publications from standards bodies and other relevant official technical sources.

WHY?

Improve decision quality

This guide explains the technical term and the criteria to consider when making purchasing, architecture or operational decisions.

LAST TECHNICAL REVIEW

Related Enterprise Solutions

Explore the related service and solution pages to plan implementation.

Let's Evaluate Your Technical Requirement

Share your current infrastructure, user count or technical objective and we can help clarify product, licensing or project scope.

Send a Technical Request
Enterprise IT Product Sales, Licensing and Deployment
Enterprise IT Project & Solution Scenarios
View all related content
Text on WhatsApp
Copied!