DMARC Setup: Stopping Email Spoofing in Plain Language

A project manager at one of your subcontractors opens an email that looks like it came from your firm's domain, asking them to redirect an invoice payment to a different account before the end of the week. The email signature matches, the domain is correct, and the tone sounds like someone from your team. The subcontractor follows the instruction, and the money disappears. Your firm never sent that email, but the subcontractor has no reason to doubt it because it appeared to come from your actual domain.

DMARC setup is the technical fix that stops other people from sending email that appears to come from your firm's own domain, and it works by adding a policy to your domain's DNS records that tells receiving email systems how to handle messages that fail authentication checks. For architecture, engineering and construction firms in and around New York City, domain spoofing has become a routine risk tied directly to project workflows, where a single fraudulent change order or payment redirect can cost more than most technology budgets. DMARC setup protects the firm's domain from being impersonated, but it requires understanding how email authentication works and rolling out the policy carefully to avoid blocking legitimate messages sent by project platforms, e-signature tools, and other services that send on behalf of your domain.

This article walks through DMARC setup in plain language for firms without a dedicated IT team, explaining how SPF, DKIM and DMARC work together, how to read the reports without a security background, and how to move from monitoring to enforcement without breaking email from Procore, Bluebeam, DocuSign, or any other platform your firm relies on to communicate with consultants, clients and contractors.

Key Takeaways

• DMARC setup stops others from sending email that looks like it came from your firm's domain by adding authentication policies to your DNS records
• A safe rollout starts in monitor mode and moves to enforcement only after reports confirm every legitimate sender is authorized
• DMARC protects your exact domain from spoofing but does not stop lookalike domains or attacks from compromised mailboxes

What Email Spoofing Looks Like at an AEC Firm

Email spoofing in architecture, engineering and construction work follows the money trail and the trust built into project relationships. Attackers forge messages that look like they came from your own domain to redirect payments, request file access, or change banking details on active jobs.

Fake invoice and change order emails that appear to come from your domain

An attacker sends a message to your client or general contractor that shows your firm's exact domain in the "From" field. The email references a real project number and requests updated wire instructions for the next draw or adds a change order with revised payment routing. The message never passed through your mail server and leaves no trace in your sent items, but the recipient sees your domain, your firm name, and often project details scraped from public permit filings or LinkedIn.

Invoice fraud tied to construction draws is particularly damaging because payment amounts are large and the window to catch the error is short. A spoofed change order email that redirects a $75,000 progress payment costs more than the payment itself when you account for the time spent with your bank, the client's accounting team, and the delay to the schedule while everyone sorts out what happened. The attack succeeds because the impersonated domain is yours, not a lookalike, so the recipient has no visual reason to question it.

Spoofed emails to consultants, subcontractors and clients using your firm's name

Attackers also send outbound messages to your project team. A structural engineer receives what looks like an email from your project manager asking for the latest foundation drawings to be sent to a new address. A subcontractor email arrives asking them to confirm updated insurance certificate delivery instructions or to use a different portal link for submittals. A client gets a message that appears to come from your principal requesting an urgent call about a budget issue.

None of these messages came from your firm, but all of them show your domain. The recipient trusts the sender because they recognize your name and domain from prior correspondence. Email spoofing that targets your consultants and subs damages your reputation even when the recipient catches it, because now every legitimate email you send carries a shadow of doubt.

Why design and construction firms are attractive spoofing targets

AEC projects involve multiple parties who do not share a single email system. Your team, the owner's representative, the cost estimator, the civil engineer, and the lighting consultant all use different platforms but exchange email constantly throughout the job. That fragmented environment makes it harder for any one recipient to verify that an incoming message actually came from your server.

Projects also create predictable cash flow events. Draw schedules, retainage releases, and change order approvals follow patterns attackers can research through public permit databases and prior project announcements. When an attacker knows your firm just submitted drawings for a commercial fit-out in Lower Manhattan, they can time a spoofed invoice to coincide with the expected payment cycle and increase the chance the recipient acts on it without additional verification.

How SPF, DKIM and DMARC Work Together

SPF authorizes which servers can send email for your domain, DKIM proves a message was not altered in transit, and DMARC ties both to a policy that tells receiving systems what to do when authentication fails and sends you reports about who is using your domain.

What SPF does and where it falls short alone

An SPF record is a line of text you add to your domain's DNS settings that lists every mail server allowed to send email from addresses at your domain. When someone sends a project update from your firm's address, the receiving system checks your SPF record to see if the sending server's IP address appears on the list.

If your firm sends through Microsoft 365, the SPF record includes Microsoft's servers. If you also send through Procore or Bluebeam notifications, those platforms' servers need to be listed too. When the sending server matches an entry in the record, SPF passes.

SPF has two weaknesses that matter for firms working on projects with consultants and subcontractors. First, it only checks the envelope sender used during the server-to-server handoff, not the visible From address a recipient sees in their inbox. An attacker can pass SPF for a domain they control while displaying your firm's name in the message header, and SPF alone will not stop it.

Second, SPF often breaks when someone forwards your email. If a structural engineer forwards your RFI to another consultant, the forwarding server's IP probably is not in your SPF record, so the check fails even though the original message was legitimate.

What DKIM adds and how signing works

DKIM signing attaches a cryptographic signature to each outgoing message using a private key your mail server holds. The signature is added as a header, and the matching public key is published in your DNS records. When the message arrives, the receiving system fetches your public key and verifies the signature.

A valid DKIM signature shows two things: the message was signed by someone holding the private key, and the signed content has not changed since it was signed. If an attachment or the body text is modified after signing, the signature breaks and DKIM fails.

Unlike SPF, DKIM generally survives forwarding because the signature travels with the message. That makes it more reliable for project correspondence that moves through multiple recipients. Hosted email providers handle DKIM signing automatically once you add the required DNS records they provide.

DKIM does not stop spoofing on its own because it only proves a signature is valid for the domain named in the signature header. That domain might not match the one your recipient sees in the From line, which is where DMARC comes in.

How DMARC ties SPF and DKIM to a policy and a report

A DMARC policy tells receiving mail systems what your firm wants done with messages that fail authentication and where to send daily reports about who is sending email as your domain. The DMARC record is published in DNS at a specific subdomain and includes a policy setting and a reporting address.

DMARC requires alignment between the domain that passes SPF or DKIM and the domain shown in the visible From address. If your firm's domain appears in the From line, either the SPF envelope domain or the DKIM signing domain must match it for DMARC to pass. This alignment requirement is what blocks spoofing that SPF and DKIM alone miss.

The policy tag in your DMARC setup can be set to three levels. A policy of none means you are monitoring without enforcement, quarantine suggests treating failures as suspicious, and reject says failures should be blocked outright. Firms start with none to collect reports and confirm every legitimate sender is properly authenticated before moving to stricter enforcement.

Reports arrive as XML files listing every source that sent email as your domain, whether each message passed or failed SPF and DKIM, and whether DMARC alignment succeeded. Reading reports is about sorting sources into authorized platforms such as Microsoft 365 and Procore versus unauthorized attempts, then fixing authentication for any legitimate sender that shows up as failing before you tighten the DMARC policy.

DMARC Setup: A Step by Step Plain Language Walkthrough

DMARC setup protects your firm's domain from being used to send phishing emails that appear to come from your firm. The process involves publishing a DNS record that turns on monitoring, checking that your legitimate email sources are properly authenticated, and setting up an address where reports arrive.

Publishing your first DMARC record in monitor mode

Your DMARC record is a TXT record published in your domain's DNS at a specific location: _dmarc.yourdomain.com. The record tells receiving mail servers what to do when email claiming to be from your domain fails authentication, and where to send reports about those messages.

The first record you publish should always use a policy of none. This is monitor mode. Messages that fail DMARC checks still reach their destination, but you receive daily reports that show which sending sources passed and which failed. This gives you visibility without risking blocked email.

A basic DMARC record in monitor mode looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]

The v=DMARC1 tag identifies the record version. The p=none tag sets the policy to monitor only. The rua tag specifies where aggregate reports should be sent.

You add this record through your DNS provider, the same way you would update any other DNS setting. Most providers let you add a TXT record by entering _dmarc as the host name and pasting the record as the value. DNS changes typically take effect within a few hours, though some providers propagate faster.

Confirming SPF and DKIM are aligned with your sending domain

DMARC works by checking that the domain in the visible From header of an email matches the domain authenticated by SPF or DKIM. This matching requirement is called alignment, and it is what makes DMARC effective at stopping spoofing.

SPF alignment means the domain that passed SPF matches your domain. DKIM alignment means the domain in the DKIM signature matches your domain. For DMARC to pass, at least one of these must align. If your firm sends from Google Workspace or Microsoft 365, both SPF and DKIM should align automatically as long as you have enabled DKIM signing in your admin console.

The challenge comes with third-party platforms that send email on your behalf. Project management tools like Procore, Autodesk Forma, formerly Autodesk Construction Cloud, or Bluebeam Studio often send notifications using your domain in the From header. If those platforms are not configured to sign messages with DKIM using your domain, or if they send from IP addresses not listed in your SPF record, DMARC will fail for those messages.

Your DMARC aggregate reports show which senders are aligned and which are not. You fix alignment issues by enabling DKIM signing on the platform, adding the platform's sending IPs to your SPF record, or working with the vendor to configure sending properly. This step takes the most time during DMARC setup because you need to catch every legitimate sender before you move from monitor mode to enforcement.

Setting up the report address and who should receive it

The rua tag in your DMARC record specifies where aggregate reports are sent. These reports arrive daily as XML files from each receiving mail server, containing data about every message that claimed to come from your domain in the past 24 hours.

The address you list should be monitored by someone who can interpret the reports and act on them. For most firms, this means either your managed IT provider or an internal operations manager. The reports are technical but not difficult to read once you understand the format. They tell you which IP addresses sent mail as your domain, how many messages passed or failed SPF and DKIM, and whether DMARC alignment succeeded.

You can specify multiple report addresses by adding additional rua tags, such as rua=mailto:[email protected],mailto:[email protected]. This sends the same report to both addresses, which is useful if your IT provider needs visibility but you also want an internal copy.

Some firms use a DMARC reporting service that receives the XML files, parses them, and presents the data in a dashboard. These services make it easier to spot patterns and identify which platforms need configuration changes. Without a service, you will need to open the XML files directly or use a script to convert them into a readable format.

Reading DMARC Reports Without a Security Background

DMARC aggregate reports show which mail servers sent email claiming to be from your domain and whether those messages passed SPF and DKIM checks. You use them to build a list of authorized senders before moving your DMARC policy from monitor mode to quarantine or reject.

What an aggregate report actually tells you

DMARC aggregate reports are XML files sent daily by receiving mail servers like Gmail, Outlook and Yahoo to the address you specified in your DMARC record. Each report covers a 24-hour period and lists every IP address that sent email from your domain during that window, how many messages each IP sent, and whether SPF and DKIM passed or failed for each source.

You will see fields for the reporting organization (which receiver sent the report), the date range covered, your domain, and your published DMARC policy. Each source IP gets its own record showing a message count, a disposition (whether the receiver delivered, quarantined or rejected the mail), and pass or fail results for SPF and DKIM.

The key information is straightforward. If both SPF and DKIM show pass for a given source, those messages authenticated correctly. If either shows fail, you need to investigate whether that sender is legitimate and fix their configuration, or whether it is an unauthorized source you want blocked once you tighten your policy.

Raw XML reports are unreadable at scale. A firm with moderate email volume receives dozens of reports per day, each containing hundreds of source records. Most firms use a DMARC monitoring tool or ask their IT provider to parse the reports automatically and identify senders by name rather than just IP address.

Spotting legitimate senders you forgot to authorize

The monitoring period exists to catch sending sources you forgot about or did not know existed. You will quickly identify your main mail server, but you may also find IP addresses belonging to Procore, Forma, Bluebeam Studio, DocuSign, your payroll provider, or a marketing platform someone in the firm set up years ago.

When a report shows a source with authentication failures but the IP belongs to a tool you recognize, that sender is legitimate but not properly configured. You need to add that service's sending servers to your SPF record or configure DKIM signing through that platform before you move to a policy of quarantine or reject. Otherwise project notifications, signed contracts and invoices sent through those platforms will start landing in spam or getting blocked entirely.

Some sources may be harder to identify by IP address alone. A reverse DNS lookup or a DMARC monitoring tool will usually resolve the IP to a recognizable hostname. If you cannot identify the source and it is sending a meaningful volume of mail, assume it is legitimate until you confirm otherwise. Contact your IT provider or the platform vendors you use to verify which IPs should be authorized.

Spotting real spoofing attempts versus noise

Unauthorized senders show up as IP addresses you do not recognize, often with SPF and DKIM both failing and a low message count. These are either spoofing attempts (someone forging your domain to impersonate your firm) or backscatter (bounced messages from forged mail sent by someone else). Both are noise you want blocked, not legitimate email.

A handful of failed messages from random IPs scattered across different countries is typical background spoofing. You will see this on any domain. It does not mean your firm has been breached or that a particular attack is underway. It means your domain is being used in the "From" line of spam or phishing emails sent by third parties, which is exactly what DMARC is designed to stop once you move to a reject policy.

High-volume failures from a single unknown source or a sudden spike in unauthorized sending may indicate a more focused attempt. DMARC reports alone do not tell you who is behind it or what the messages said, only that the volume is unusual. If you see this pattern, mention it to your IT provider or security contact so they can review whether other indicators suggest targeted activity.

The point of reading DMARC reports is not deep forensic analysis. You are sorting sending sources into two groups: legitimate senders you need to authorize, and unauthorized senders you want blocked. Once you have confirmed every legitimate source passes SPF and DKIM, you can safely move your DMARC policy to quarantine and then reject without breaking project email or client correspondence.

Moving From Monitoring to Enforcement Safely

The step from monitoring to enforcement is where most DMARC setups either protect your domain or accidentally block project emails. Moving too fast risks quarantining legitimate messages from construction platforms, consultant firms or vendors, while staying at monitor mode indefinitely leaves your domain unprotected against spoofing.

Why jumping straight to reject can block real email

Setting your DMARC policy straight to reject before you know every legitimate sender passes authentication means real business email can get blocked without warning. A change order sent through a document platform that uses your domain, a Procore notification to a general contractor, or an invoice from your accounting system could all end up quarantined or rejected if those services aren't properly authorized through SPF or DKIM.

The risk is highest for firms using multiple outside platforms that send email on their behalf. Each service needs its own authentication configuration, and if even one is missed during the monitoring phase, enforcement can block critical project communication. That's why the enforcement move needs to follow clean reports showing that every sender you recognize is passing DMARC, not a fixed timeline.

The gradual path from none to quarantine to reject

A safe rollout moves through three DMARC policy stages in order: none, quarantine and reject. You start at none to collect reports without affecting mail delivery. Once reports show all legitimate senders passing authentication for at least two weeks with no new unexpected sources appearing, you move to quarantine.

Quarantine tells receiving servers to treat failing messages as suspicious, typically sending them to spam folders rather than the inbox. This phase confirms your DMARC setup is working without the hard stop of reject. After another period of clean reports at quarantine, usually two to four weeks, you can move to reject, which instructs servers to block unauthenticated email entirely.

Each step depends on what the reports show, not the calendar. If a new sender appears mid-rollout because your team starts using a proposal tool or bid platform, you pause enforcement, authenticate that sender and confirm it passes before continuing.

How long a safe rollout typically takes and what changes it

A straightforward DMARC rollout with few outside senders can reach reject in six to eight weeks. Firms using many platforms such as project management software, client portals, marketing tools and document sharing services should expect ten to twelve weeks or longer, because each sender needs time in the monitoring data and may require its own authentication setup.

The main variable is how many different services send email as your domain and how quickly you can work through the list to authorize each one. A small firm sending most email directly from Microsoft 365 or Google Workspace mailboxes will see a shorter path than a larger firm relying on Bluebeam Studio notifications, bid invitations through a procurement platform and automated reports from cost tracking software.

What changes the timeline is discovering a sender mid-rollout that wasn't visible in early reports, often because it sends infrequently or only during certain project phases. Extending the monitoring window to cover a full billing cycle or project milestone reduces the chance of a surprise later during enforcement.

DMARC Setup for Firms Using Microsoft 365 or Google Workspace

Microsoft 365 and Google Workspace each handle DMARC setup through their own DNS management systems, and both require you to account for shared mailboxes, distribution lists, and any hybrid mail environments that send through multiple paths.

Where these records live in each platform's admin console

Microsoft 365 manages your DMARC record in the DNS settings at your domain registrar, not inside the Microsoft 365 admin center itself. You add the DMARC TXT record at the same place where you originally verified your domain, typically through providers like GoDaddy, Cloudflare, or Network Solutions. The exception is your .onmicrosoft.com address, which you configure directly in the admin center under Settings > Domains > DNS records.

Google Workspace also requires you to add the DMARC record at your domain host, not inside the Google Admin console. You navigate to the same DNS management panel where you added your MX records and SPF record when you first set up Google Workspace. Both platforms publish documentation showing the record format, which follows the standard DMARC syntax starting with _dmarc as the hostname.

The actual DNS provider interface varies by registrar, but the DMARC record type is always TXT, the hostname is always _dmarc, and the value includes your DMARC policy, percentage, and reporting addresses. You set up SPF and DKIM through each platform's mail authentication settings before adding your DMARC record.

Handling shared mailboxes and distribution lists

Shared mailboxes in Microsoft 365 send mail through the Exchange Online servers using the same SPF and DKIM paths as regular user mailboxes, so they align with your DMARC policy automatically as long as you have not enabled external relay through a third-party service. Distribution lists function the same way, since they simply forward messages sent from authorized accounts.

Google Workspace groups and collaborative inboxes also route through Google's mail servers and inherit the same authentication as individual accounts. Problems show up when you connect an external platform such as Procore or Bluebeam Studio to send project notifications from a shared address like [email protected]. Those platforms need SPF authorization or a DKIM signing key configured in the platform's settings.

You identify these sending paths by reviewing DMARC aggregate reports during your monitoring phase. Any source that sends as your domain but does not appear in your Microsoft 365 or Google Workspace tenant will show up as a failed alignment, and you add that source to your SPF record or configure DKIM signing for it before tightening your DMARC policy.

What changes if your firm uses a hybrid or migrated mail setup

A hybrid setup where some mailboxes remain on an on-premises Exchange server while others have moved to Microsoft 365 creates two outbound paths, and both need SPF authorization. Your SPF record must include the IP addresses or hostnames for your on-premises server in addition to the include:spf.protection.outlook.com mechanism for Microsoft 365.

DKIM signing during a migration depends on which server sends the outbound message. Mail routed through Microsoft 365 uses the DKIM selector you configured in the Microsoft 365 admin center, while mail sent from on-premises Exchange uses the DKIM key configured on that server. Both signatures align with your domain as long as the signing domain matches your From address domain.

A firm partway through migrating from Google Workspace to Microsoft 365 or the reverse needs both platforms authorized in the SPF record until the migration completes. The DMARC policy applies to the domain regardless of which platform sends a given message, so any platform sending as your domain must pass SPF or DKIM alignment. You confirm alignment by monitoring reports from both sources before you move your DMARC policy from none to quarantine.

Authorizing the Tools Your Firm Actually Sends From

Many emails carrying your firm's domain do not come from your mailbox. Notifications from Bluebeam Studio, Procore or Forma, proposal tools and e-signature platforms all send as your firm, and each one must be authorized in your SPF record or configured to sign with your DKIM key before you can enforce your DMARC policy.

Project platforms and notification emails from software your teams use daily

Bluebeam Studio sends session invites and markup notifications to external consultants and reviewers. Procore sends daily logs, RFI responses and submittal alerts to subcontractors and the project team. Forma sends model coordination notifications and document sharing alerts. Each platform sends these messages as your domain so replies reach the right person in your firm.

Most platforms support custom DKIM signing, which lets the service sign outgoing messages with your domain's key. Log into the platform's admin settings and look for email authentication or domain verification. You will usually add a DNS record the platform provides, then enable custom DKIM in the dashboard. Once configured, the platform's messages pass DKIM alignment and your DMARC setup sees them as authorized senders.

If a platform does not support custom DKIM, you need to add its SPF include to your domain's SPF record. The platform's documentation will give you the include statement. Add it to your SPF record alongside your other authorized senders, keeping in mind that SPF has a limit of ten DNS lookups. Check your DMARC reports after making the change to confirm messages from the platform now pass.

Marketing, proposal and e-signature tools that send as your domain

Proposal tools and e-signature platforms send contracts, change orders and fee agreements to clients and lenders. These messages carry your firm's name in the From line because the recipient expects to receive them from your firm, not from a generic software domain. Marketing platforms send newsletters, project announcements and event invites using your domain for the same reason.

E-signature platforms such as DocuSign and similar services typically support custom DKIM and domain verification. Configure these settings before tightening your DMARC policy so signed documents reach clients without landing in quarantine. Proposal tools vary in their support for authentication. Check whether the tool allows you to configure SPF or DKIM, and if it does not, ask whether it can send from a subdomain such as proposals.yourfirm.com with its own authentication.

Marketing platforms usually provide detailed instructions for adding SPF includes and configuring DKIM signing. Follow their setup guides and verify the changes in your DMARC reports. If a tool cannot be authenticated and does not support subdomains, consider whether it truly needs to send from your primary domain or whether recipients will accept messages sent via the tool's own domain.

What happens to unauthorized senders once DMARC is enforced

At p=none, unauthorized senders appear in your DMARC reports but their messages still deliver. This monitoring mode gives you time to identify every platform and authorize it before enforcement begins. Move to p=quarantine only after several weeks of reports show all legitimate senders passing authentication.

At p=quarantine, messages from unauthorized senders land in spam or junk folders. A project notification from Forma that is not properly authorized will not reach the superintendent's inbox. An e-signature request that fails authentication may never be seen by the client. These failures happen silently from the sender's perspective, so you will only know about them when someone reports that they did not receive an expected message.

At p=reject, unauthenticated messages are blocked entirely and never delivered. This is the strongest protection against domain spoofing, but it requires certainty that every legitimate sender is authorized. A single forgotten platform will cause delivery failures as soon as you publish the reject policy. This is why the monitoring period matters and why you should advance your DMARC policy only after your reports confirm that all authorized senders pass for at least two weeks without exceptions.

Common DMARC Setup Mistakes That Break Legitimate Email

Three technical mistakes appear in almost every failed DMARC rollout, and each one quietly breaks legitimate email without warning. Publishing more than one SPF record disables SPF entirely. Enabling DKIM in your sending platform's dashboard but forgetting to publish the matching DNS record leaves messages unsigned. Using a subdomain for recruiting or marketing newsletters without covering it in your DMARC policy lets those messages fail authentication while your main domain appears fine.

Multiple SPF records and why only one is allowed

DNS allows only a single SPF record per domain. If you publish two separate TXT records that both begin with v=spf1, mail servers will ignore SPF entirely and treat the result as a configuration error.

This usually happens when someone adds a second record for a new platform instead of editing the existing one. A firm might have one SPF record authorizing Microsoft 365, then add a separate record for a project management system's transactional email, not realizing the first record must be updated to include both sources.

The consequence is immediate. SPF stops passing for every sender, including your main office mailboxes. If your DMARC policy relies on SPF alignment and DKIM is not configured, project emails to consultants and invoices to clients will start failing authentication. Some receivers will deliver them to spam. Others will block them outright if you have already moved to an enforcing DMARC policy.

Before adding any new include: statement, check what is already published at your domain. You should see exactly one TXT record at the root domain that starts with v=spf1. Add the new platform's include mechanism to that existing record rather than creating a second one. If you find two records already published, consolidate them immediately into a single record that lists every authorized sender.

DKIM keys that were published but never actually turned on

DKIM requires two steps, and missing either one leaves your messages unsigned. First, you generate a key pair in the sending platform and publish the public half as a DNS record at a specific selector hostname. Second, you enable signing in the platform's settings so it actually attaches a DKIM signature to every outgoing message.

Many firms complete the first step and assume the work is done. They publish the DNS record because the platform's setup guide told them to, but they never flip the switch in the platform itself to turn signing on. The DNS record sits idle. Messages leave without a signature, and DMARC alignment fails.

The symptom is that DMARC reports show a particular sending source with dkim=fail or dkim=none even though you know you published the key. The platform is authorized, the DNS is correct, but no signature is attached because signing was never activated in the software.

This happens frequently with project collaboration platforms like Procore or Forma, where the firm administrator sets up the DNS but does not realize a separate "enable email signing" toggle exists in the admin console. Change order notifications and document alerts leave unsigned, and when you move your DMARC policy to reject, those notifications stop reaching subcontractors and clients.

Before moving past monitor mode, confirm that every platform in your DMARC reports is both publishing a key and actively signing. Most platforms will let you send a test message and inspect the headers to verify a DKIM signature is present.

Forgetting subdomains used for marketing or job applications

A DMARC record at your main domain covers that domain and, by default, any subdomain that does not have its own record. But if you actively send email from a subdomain and forget to account for it, messages from that subdomain will fail authentication when you enforce your policy.

Architecture and engineering firms often use a subdomain like careers.yourfirm.com for job application systems or news.yourfirm.com for firm newsletters. These systems send email that appears to come from the subdomain, not the main domain. If the subdomain has its own sending platform and that platform is not aligned, every message fails DMARC when you move to reject.

The mistake is assuming the main domain's SPF and DKIM setup automatically covers the subdomain. It does not. Each subdomain needs its own SPF record if it sends mail, and any DKIM signature must align with the subdomain or the organizational domain depending on how the platform is configured.

The subdomain policy tag sp= in your main DMARC record controls what receivers should do with mail from subdomains that lack their own DMARC record. If you set sp=reject without first aligning every subdomain sender, recruiting emails and newsletters will bounce. Many firms discover this only after candidates stop receiving application confirmations or clients ask why the monthly project update never arrived.

Check your DMARC reports for any subdomain traffic before you enforce. If a subdomain appears and is sending legitimate mail, either align it properly or publish a separate DMARC record at that subdomain with its own monitoring period. If a subdomain appears that you do not recognize and is not legitimate, setting sp=reject at the organizational domain will block it, which is exactly what you want.

What a Completed DMARC Setup Protects Against and What It Does Not

A DMARC record stops someone from sending email that appears to come directly from your domain, but it does not stop lookalike domains, compromised mailboxes, or phishing emails that never claim to be from you. It is one layer in your email security, not a complete solution on its own.

Direct domain spoofing versus lookalike domains

DMARC protects your exact domain name. If someone tries to send email claiming to come from yourfirm.com, and you have a DMARC policy in place alongside SPF and DKIM, the receiving mail server will check whether that sender is authorized. If the email fails both SPF and DKIM alignment, your DMARC policy tells the recipient server what to do: monitor it, quarantine it, or reject it outright.

This stops direct domain spoofing, where an attacker forges your domain in the "From" field to trick a subcontractor, client, or lender into thinking the email came from you. Without DMARC, those spoofed emails often reach the inbox.

DMARC does nothing against lookalike domains. If someone registers yourfirm-nyc.com or yourfirm.co and sends email from that domain, DMARC on yourfirm.com will not trigger. The lookalike domain is a separate domain entirely, and the attacker can set up their own DMARC record if they choose. The recipient has to notice the difference in the address, which many people miss when scanning email quickly on a phone between site visits or meetings.

Why DMARC will not stop every phishing or invoice fraud attempt

DMARC only acts when someone claims to send email as your domain. Many phishing attacks do not make that claim at all. An attacker might send email from a Gmail address or a lookalike domain, impersonating your firm by name and logo but never forging your actual domain in the email headers.

Invoice fraud often works the same way. Someone sends a fraudulent change order or payment redirect from a slightly altered address or a compromised mailbox belonging to a real person at a subcontractor or vendor. If that mailbox is legitimate and properly authenticated, DMARC on your domain has no role in stopping it. The email passed all authentication checks because it came from the domain it claimed to come from.

A compromised mailbox is another gap. If someone gains access to a real email account at your firm or a consultant's firm, they can send email through the legitimate mail server. That email will pass SPF, DKIM, and DMARC because it is technically authorized. DMARC cannot distinguish between a legitimate user and an attacker using stolen credentials.

Where DMARC fits alongside the rest of your email security

DMARC is domain spoofing protection, not a complete email security solution. It works alongside spam filtering, malware scanning, multifactor authentication on mailboxes, and staff training on recognizing phishing attempts. Each layer addresses a different attack vector.

Spam filters and malware scanners check the content and attachments of incoming email, catching threats based on known patterns and behavioral signals. DMARC checks the sender's authorization based on DNS records. MFA on your mailboxes stops attackers who steal a password from logging in remotely. Training helps project managers and principals recognize suspicious requests even when the technical details look correct.

ELMIDA's email security service covers DMARC setup as part of a layered approach that includes spam filtering, mailbox authentication, and monitoring for your firm. A full DMARC setup is necessary, but it does not replace the other layers. You need all of them working together to reduce risk across the different ways email attacks reach your firm, your consultants, and your clients.

Keeping DMARC Setup Working as Your Firm Changes

DMARC setup is not a once-and-done task. When you add new project software, open a new office with its own email flow, or merge with another firm, your SPF, DKIM and DMARC records need to be updated to reflect those changes or legitimate mail will start failing authentication.

Reviewing records when you add new software or open a new office

Every time you add a new software vendor that sends email as your domain, your DMARC setup needs a corresponding update. When you start using a new project platform like Procore or Forma, or add an e-signature tool that sends contracts and change orders from your domain, that vendor needs to be authorized in your SPF record and its DKIM selector needs to be published in your DNS. If you skip this step, the new vendor's messages may land in spam or be rejected.

The same applies when you open a branch office that sends mail through its own infrastructure or mailboxes. If the new location sends from your domain through a different mail server or IP range, that server needs to be added to your SPF record. Your DMARC reports will show authentication failures from the new location until the records are updated.

Set a calendar reminder to review your DMARC setup quarterly, or at minimum whenever you sign a contract with a new vendor that will send email on your behalf. This review should include checking aggregate reports for any unexpected authentication failures and confirming that your SPF record is still under the 10 DNS lookup limit.

What changes when a firm is acquired or merges domains

A domain merger creates immediate DMARC review work because the combined firm now sends mail from multiple domains, each with its own authentication setup. If your firm acquires another practice and continues using both domains, each domain needs its own DMARC record and each needs SPF and DKIM records that cover all sending sources used by that domain. You cannot apply one domain's DMARC policy to another domain. DMARC only protects the exact domain it is published for.

If the combined firm consolidates to a single domain and migrates mailboxes, the old domain should be left with a DMARC policy of reject to prevent spoofing after the migration is complete. During the migration period, continue monitoring DMARC reports from both domains to catch any mail flows that have not been migrated yet.

Assigning ownership so DMARC does not get forgotten after launch

Assign one person or your IT provider as the owner responsible for ongoing DMARC record maintenance. Without clear ownership of email security, DMARC setup gets forgotten until something breaks, usually when a new vendor's project notifications start landing in spam and no one knows why.

The person assigned should review DMARC reports monthly, or at minimum quarterly, and should be notified whenever the firm adds new software, opens a new location, or makes changes to mail flow. This does not require deep security training. The task is mainly sorting sending sources in the reports into legitimate and unauthorized, then updating SPF and DKIM records as needed.

If your firm works with an outside IT provider, confirm that DMARC review is part of the service agreement and that they will notify you if reports show authentication failures or unauthorized sending attempts. Many firms set up DMARC correctly but then let it drift out of sync with their infrastructure because no one is watching the reports.

DMARC setup raises practical questions about how it fits with existing email security, whether it will disrupt project communications, and what it costs to maintain once you put it in place.