DMARC Implementation Services
Your invoices, staff email and business applications may all send using your domain. Establish which senders are legitimate before changing the rules that receiving systems use to evaluate their mail.
The short answer
DMARC is a DNS record that tells receiving mail servers what to do with messages that claim to come from your domain but fail SPF and DKIM alignment, and where to send reports about them. DMARC implementation means finding every service that sends as your domain, aligning SPF and DKIM for each one, then moving the policy in stages from p=none through quarantine to reject while the reports are reviewed. NetSys scopes and runs that project, and ongoing report monitoring, provider fees and work outside the project are quoted separately.
A business domain can appear in messages from Microsoft 365, an invoicing platform, a CRM, a website form and a marketing provider. The person who administers email may not own all of those systems. Begin with a sender inventory and a named contact for each service so the project can distinguish approved mail from unfamiliar activity.
Bring your domain names, the services that send messages, who controls DNS and examples of reported delivery problems. Do not include passwords or private message contents in the initial enquiry. We agree access, change approval, the test plan and the expected deliverables before making changes to your environment.
Use a controlled rollout with evidence for each decision
Agree a representative test for each important workflow: a staff message, an invoice, a website notification and an application alert, where those senders exist. Record the source, owner, result and unresolved dependency. Make enforcement decisions after reviewing legitimate sending paths, and agree how to respond if an approved workflow is affected. A DNS record alone is not a complete project handover.
What the implementation scope can include
Sender and domain assessment
Establish what belongs in the project before approving changes.
- Sending domains and subdomains, current DNS records and ownership
- Business sender inventory with a contact for each application or supplier
- Known failures, duplicate configurations and unresolved ownership questions
- Registered domains that never send mail, marked for a reject policy
SPF and DKIM alignment
Coordinate settings across DNS, Microsoft 365 and the agreed sending services.
- Review authorized sending sources and domain alignment
- DKIM signing with your own domain at each service, so the signature aligns with the From address
- A subdomain with its own record for any service that cannot sign as your main domain
- Document the proposed records and required provider-side settings
- Obtain approval for changes and record the prior configuration
Gradual enforcement
Move from monitoring to rejection only as fast as the reports allow.
- A p=none policy first, with reports reviewed before anything is enforced
- Quarantine next, applied to a share of failing mail at first where that helps
- Reject once the reports show that only unauthorized mail is failing
- Lower-volume domains and subdomains first, with the main domain last
- Representative sender tests and a record of the observed results at each stage
Monitoring and ongoing reporting
Give the domain a clear operating owner after setup.
- Aggregate reports sent to a dedicated mailbox, not one person's inbox
- Reviews weekly during rollout and monthly once stable, the cadence Microsoft suggests
- Named reporting owner, a record of approved senders and outstanding actions
- A process for checking new senders before another system starts using the domain
Treat sender authentication as an owned business process.
Tell us which domains and email platforms you use, whether a DMARC policy already exists and what prompted the review. We will define the configuration, testing and reporting work before proposing a project.
Who does the work: meet the NetSys team on our About page.
- Project scope separates initial setup from continuing monitoring
- Testing covers agreed business senders, not just an individual mailbox
- Records, changes and unresolved supplier dependencies are documented
DMARC Implementation Services FAQs
What is DMARC?
DMARC, short for Domain-based Message Authentication, Reporting and Conformance, is an email authentication method published as a TXT record in your domain's DNS. It checks that a message which passes SPF or DKIM also aligns with the domain in the From address, tells receiving servers what to do when it does not, and asks them to send reports back. Its job is to stop other people sending mail with your exact domain in the From line.
What is a DMARC record, and what does one look like?
A DMARC record is a TXT record published at _dmarc.yourdomain.com. A monitoring record looks like v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com, where v identifies the record, p sets the policy and rua says where aggregate reports go. Optional tags include aspf and adkim, which set relaxed or strict alignment. The current DMARC standard, RFC 9989, retired the old pct tag, which applied the policy to a percentage of failing mail, and replaced it with t=y, a testing flag.
What is the difference between DMARC quarantine and reject?
Both apply only to mail that fails DMARC. With p=quarantine the receiving server accepts the message but marks it, usually by sending it to the junk folder or a quarantine. With p=reject it should refuse the message, and Microsoft 365 rejects it during delivery. A p=none policy takes no DMARC action and is used to collect reports. Microsoft's recommended path runs from none to quarantine to reject, with the reports checked at each stage.
What does a DMARC failure mean?
It means neither SPF nor DKIM produced a pass that aligns with the domain in the From address. For legitimate mail, the usual causes are a service such as a CRM or invoicing platform sending as your domain without DKIM signing in your name, or a message forwarded through another server. For spoofed mail, failing is the point: it is how the receiving server knows to apply your policy.
How do you set up DMARC?
Set up SPF and DKIM for every service that sends as your domain first; Google asks you to allow 48 hours after that before adding DMARC. Then publish a TXT record at _dmarc with p=none and a reporting address, review the aggregate reports until every legitimate sender passes, and move to quarantine and then reject. Start with low-volume domains or subdomains and leave the main domain for last.
Does Gmail require DMARC?
For bulk senders, yes. As of October 2026, Gmail's sender guidelines require anyone sending more than 5,000 messages a day to Gmail accounts to set up DMARC for the sending domain, and a p=none policy meets that requirement. Most small businesses send far less, but DMARC is still the control that stops strangers sending mail as your domain. For a Google Workspace domain, the record is published the same way as for Microsoft 365: a TXT record at your DNS host.
What is the difference between SPF, DKIM and DMARC?
SPF identifies permitted sending sources; DKIM provides a domain signature. DMARC checks whether a passing SPF or DKIM result aligns with the domain shown in the From address, and publishes a policy and reporting instructions. An implementation reviews the combination rather than treating three DNS records as interchangeable controls.
Can you configure DMARC for Microsoft 365?
Yes. DMARC configuration is part of NetSys's published Microsoft 365 security work. This project makes the domains, sending services, DNS responsibilities, tests and handover explicit. Your Microsoft 365 tenant may be only one of the systems sending mail under the domain, so the scope should identify other approved senders too.
Should we change the policy to reject immediately?
Microsoft recommends a gradual rollout with testing to avoid rejecting legitimate mail. The starting point depends on your current configuration and sending inventory. NetSys proposes the stages and acceptance checks for your environment, with business approval before enforcement changes.
Will DMARC stop every phishing message or guarantee inbox delivery?
No. It helps receiving systems evaluate use of your domain, but lookalike domains and compromised legitimate accounts remain risks. Receiving systems also make their own delivery decisions. Keep mailbox protection, identity controls and staff verification practices alongside domain authentication.
Can the project include our CRM, invoicing or marketing platform?
Those senders can be included in an agreed scope. We identify the platform owner and its supported authentication settings, then coordinate configuration and testing. A supplier may require its own license, administrator action or support request. We record those dependencies rather than promising that every application can be changed in the same way.
How much do DMARC implementation services cost?
The quote depends on the number of domains and senders, the state of the current records, access to DNS and platforms, investigation needed, testing requirements and reporting arrangements. Initial configuration and an ongoing review service are separate decisions. The proposal identifies NetSys fees, any reporting-provider fees, deliverables and exclusions.
Is ongoing DMARC monitoring included?
Only when the agreement says so. The project handover identifies who receives and reviews reports, how new senders are approved and where issues are escalated. If you want NetSys to provide continuing review, we scope the domains, cadence, investigation and change responsibilities explicitly.
Guides on this topic
Give every legitimate sender a clear path and owner.
Share your domains, sending platforms and current concerns. We will scope the authentication changes, testing and reporting your business needs.