Meeting Gmail and Yahoo bulk sender requirements with self-hosted email
Your self-hosted platform does not meet Gmail and Yahoo bulk sender rules on its own. listmonk or Mautic decides what gets sent and to whom, but the requirements that mailbox providers enforce sit in the sending domain, the DNS records that authenticate it, the unsubscribe handling in each message, and the complaint data that comes back from the sending service. Those are the pieces you must configure and own. Since February 2024, these providers have expected bulk senders to authenticate mail with SPF and DKIM, align the domain in the visible From address with DMARC, offer a one-click unsubscribe, and keep spam complaints below the level they publish. Confirm the current wording and thresholds directly with Google's and Yahoo's sender guidelines before you finalize your setup, because provider rules change and this page does not reproduce their text.
Start with a decision and a check. Decide which domain or subdomain will carry newsletters, and confirm that it is separate from the domain used for account and transactional mail where that split matters to you. Then, with your DNS administrator and your sending service, verify that SPF and DKIM pass for that domain, that DKIM signs with a domain you control, and that a DMARC policy is published and aligned with the From domain. In listmonk, the sending settings and SMTP or API configuration determine which domain signs the message. In Mautic, the transport and the cron-driven send process determine it. Test the results with real messages to major mailboxes, not only with a test tool.
Plan for the unsubscribe and complaint side as an operating task. Confirm that the list-unsubscribe headers your platform emits support one-click processing, and that a subscriber who clicks is removed from the relevant list without a login step. Ask your sending service whether it forwards feedback loop complaints and bounce events back to your platform, and who in your team reviews complaint rates each week. A complaint spike usually points to list sourcing or content problems, so keep consent records for each subscriber alongside the mail logs. Ask any implementation partner to write these checks into the handover runbook, including the owner of each DNS record and the review cadence.
Which senders the rules reach and what changes for a self-hosted platform
The bulk sender rules apply to the domain and the mail stream, not to the software that produced the message. A self-hosted listmonk or Mautic platform therefore inherits the same obligations as a SaaS sender, and the six components below decide whether those obligations are met.
Sending domain
The sending domain carries the reputation and the authentication records. SPF, DKIM and DMARC are published in DNS for the domain in the From address, and the signing domain must align with it. Check which domain your platform uses in the From header, the envelope sender and the DKIM signature, and confirm that all three point to domains you control. Keep marketing, transactional and internal mail on separate subdomains so that a problem in one stream does not damage the others.
Sending service
listmonk sends through SMTP servers that you configure, with multi-threaded queues and rate limiting. Dittofeed connects to providers such as SendGrid and Amazon SES and does not send mail itself. Either way, the service you choose controls signing, retries, bounce handling and the IP pool. Ask the provider which authentication settings it enforces, how it handles bounces and complaints it receives, and whether it supports the one-click unsubscribe header on your domain.
IP reputation
Mailbox providers score the sending IP address as well as the domain. If you relay through a managed service, confirm whether the IPs are shared with other customers and who controls the pool. If you run your own MTA, you own the reputation history, so a new address needs a gradual volume increase before large sends. Ask the sending provider for its warm-up guidance and for the procedure it follows when an address is listed by a blocklist.
List source
Mailbox providers and complaint rates respond to how addresses were collected. listmonk supports single and double opt-in lists, and Mautic segments and campaigns depend on how contacts entered the database. Imported lists, purchased lists and old contacts who never confirmed interest are the most common source of complaints. Confirm how each list was obtained, which opt-in method applies to it, and whether the platform records consent so you can show the source later.
Complaint feedback
Spam complaints reach a sender through feedback loops that mailbox providers offer and through the complaint events your sending service reports. A self-hosted platform must receive those events and act on them, usually by suppressing the address. In Mautic, the cron jobs and the messenger consumer must run for queued email to be processed. In listmonk, the bounce and link analytics show where problems start. Confirm which feedback loops you are enrolled in and who receives the reports.
Monitoring and reporting
Each component needs a metric someone reviews. Track authentication results, bounce and complaint rates, queue depth and delivery time for each stream, and set alerts when a value moves against its normal range. Keep a record of configuration changes to DNS, sending settings and list imports so that a drop in inbox placement can be traced to a cause. Assign an owner for each dashboard and agree in writing who responds when a mailbox provider begins to reject or defer messages.
Mapping SPF, DKIM, DMARC, one-click unsubscribe and spam rates to listmonk and Mautic settings
This table maps each bulk sender requirement to what the sending function must do and where it is configured in listmonk or Mautic. Read each row as a checklist item: the platform setting is where you apply it, and the sending service usually determines whether the header or signing requirement is met. Confirm exact header behavior with your chosen sending service and its documentation before you sign off on a configuration.
| Requirement | What the sending setup must do | Where to configure it in listmonk or Mautic |
|---|---|---|
| SPF alignment | The envelope sender domain used for bounces must authorize the sending service, and it should align with the visible From domain used for campaigns. | listmonk: SMTP server settings and the sending domain in the From address. Mautic: email transport settings and the From address in the email configuration. Confirm the Return-Path domain with your sending service. |
| DKIM signing | Messages must be signed for the sending domain by the sending service, with the key published in DNS under that domain. | The signing happens at the sending service or relay, not in listmonk or Mautic itself. Confirm the selector, key publication and whether the service signs every SMTP path you configure. |
| DMARC policy and reporting | The sending domain needs a published DMARC record that passes through SPF or DKIM alignment, with reporting addresses to monitor failures. | Configured in DNS for the sending domain, not inside either platform. Start with a monitoring policy, review aggregate reports, then tighten the policy once legitimate senders pass. |
| One-click unsubscribe headers | Bulk messages need a List-Unsubscribe header and a one-click POST endpoint that processes the request without requiring a login or extra steps. | listmonk: the unsubscribe link and list settings in the campaign template and list configuration. Mautic: the unsubscribe handling in email templates and the public unsubscribe route. Confirm the header is added and passed through by your transport. |
| Unsubscribe processing speed | Opt-outs must take effect quickly so later campaigns do not reach the subscriber, including across all lists the subscriber belongs to. | listmonk: subscriber status and list membership changes applied by the unsubscribe endpoint. Mautic: contact do-not-contact status and segment updates driven by cron jobs. Test the full path from click to suppression. |
| Spam complaint rate monitoring | The sender must track complaints as a share of delivered mail and act before the rate rises, using the feedback loop data from mailbox providers. | listmonk: campaign analytics and bounce or complaint records by campaign. Mautic: email statistics and contact activity. Confirm which provider feedback loops your sending service forwards. |
| Bounce handling | Hard bounces must suppress addresses, and soft bounces should be retried or limited, so repeated sends to bad addresses do not damage reputation. | listmonk: bounce settings and actions in the bounce configuration. Mautic: bounce handling through the mailer callback or bounce processing commands. Confirm the webhook or return-path feed from your sending service reaches the platform. |
| Sending rate and queues | Volume must stay within the sending service limits, and queues must keep failed sends from being lost or retried in bursts. | listmonk: multiple SMTP servers and rate limits in settings. Mautic: the broadcasts command, the messenger consumer and cron staggering. Ask the service for its per-minute and daily limits in writing. |
How listmonk, Mautic and Dittofeed each handle sending and headers
listmonk is a standalone binary with PostgreSQL as its only dependency, and it sends through its own queues to one or more SMTP servers. That makes it the option where your team controls the most of the sending path directly. Its campaign and transactional messages leave through the SMTP settings you define, so the envelope sender, the From header and the authentication tied to those servers are configured in the application and in your DNS.
- SMTP configuration: Define one or more SMTP servers in the settings, each with its own credentials and rate limit. Confirm that the sending domain in the From address matches a domain you can publish SPF and DKIM records for.
- Queues and rate limits: listmonk's multi-threaded queues spread sends across the configured servers. Set limits with your provider's throttling rules in mind, since mailbox providers judge the pace of new senders as well as the content.
- Unsubscribe handling: Campaign templates include the unsubscribe link and list-level settings. Confirm with the listmonk documentation whether the one-click unsubscribe header is emitted for your version and list type, and test it on a live message.
- Transactional API: Pre-defined templates sent through the API should use a separate sending domain or subdomain where possible, so authentication results stay distinct for each stream.
- Sending service responsibilities: Your provider typically holds the sending IP reputation, handles feedback loops and bounce processing, and may add or rewrite headers. Ask which DKIM signing keys it uses and whether it signs with your domain.
Before launch, check SPF, DKIM and DMARC results on a test message to a mailbox you control and confirm the unsubscribe header appears.
Mautic is a PHP application built on Symfony, and it can send mail through its own transport configuration. Its operating model adds scheduled work to the sending path: cron jobs update segments and campaigns, a broadcasts command sends segment emails, and a messenger consumer processes queued messages. Those background processes must run reliably, or messages stall even when the mail configuration is correct.
- Hosting requirement: The Mautic project states that it should not run on shared hosting and recommends a VPS or dedicated server. Plan the sending host, its outbound IP and its DNS records as one unit.
- Stack requirements: Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, and MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, served by Apache, Nginx or IIS. Confirm the exact requirements for the release you install.
- Cron and messenger: Stagger the cron jobs as the documentation advises, and keep the messenger consumer running under a process supervisor. If it stops, queued email stops with it.
- Transport and headers: Configure the mail transport and sender identity in the application settings. Verify in your own test sends whether List-Unsubscribe and List-Unsubscribe-Post headers are present, and do not assume they are.
- Sending service responsibilities: If you relay through an external provider, that provider holds IP reputation, bounce feedback and any DKIM signing you delegate to it.
Before launch, confirm that every cron job and the messenger consumer run on schedule and that test messages show passing authentication results.
Dittofeed is an omni-channel engagement platform that builds segments and journeys from user data, then passes email to a provider. It integrates with services such as SendGrid and Amazon SES rather than sending email itself. For bulk sender compliance, this means the authentication and unsubscribe behavior of each message is shaped mostly by the provider and by the domain setup you give it, with Dittofeed controlling the content and the journey logic.
- Provider integration: Connect a supported email service provider and confirm that it signs messages with your domain's DKIM keys. The DNS records and the provider's sending domain verification belong to your team.
- Templates and headers: Templates are authored in HTML, MJML or a low-code editor, and they can be kept in git. Check whether the unsubscribe link and any list-unsubscribe header are added by Dittofeed, by the provider or by the template itself.
- Release status: Recent GitHub releases are pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026. Treat the current build as pre-production for regulated sending until you have tested the version you plan to run.
- Deployment: Docker Compose, Render and Helm charts are documented in the repository. Keep the deployment inside your own VPC if user data must stay there.
- Testing: The testing SDK can check campaigns in CI, which helps confirm that unsubscribe elements exist before a release.
Before launch, ask the provider which headers it adds, which domain it signs with, and how it returns bounce and complaint data to Dittofeed.
How the authentication and unsubscribe rollout is sequenced
The sequence makes each sending domain provably authenticated and reversible before volume grows, so mailbox providers see a consistent, identifiable sender and recipients can leave with one click. Each step produces a check that the next step depends on.
Choose and verify the sending domain
Decide which domain or subdomain will carry marketing and which will carry transactional mail, so that reputation stays separate between the two streams. Your team confirms ownership of the domain, agrees who controls its DNS records, and records the sending addresses that listmonk or Mautic will use. Done means every planned sender address resolves to a domain your organization controls, and the owner of each DNS zone is named in writing.
Publish SPF and DKIM through the sending service
Obtain the SPF include and the DKIM signing keys from your sending service, which may be an SMTP relay, an email API or your own mail server. DeployOpen's engineers publish the records in DNS and configure the signing settings so that the sending service signs messages with the same domain shown in the From header. Done means that test messages pass SPF and DKIM checks and that the DKIM signature domain aligns with the From domain.
Set a DMARC policy and reporting address
Publish a DMARC record that starts with monitoring and names a mailbox for aggregate reports, then review those reports to confirm that legitimate sources align. Tighten the policy only after the reports show that every sending source you use is authenticated and aligned. Done means a DMARC record is live, reports arrive at the agreed address, and every legitimate sending source appears as aligned.
Configure one-click unsubscribe
Enable the List-Unsubscribe and List-Unsubscribe-Post headers in each list or campaign template, and point the endpoint at the listmonk or Mautic unsubscribe handler on your own domain. Confirm that a single request from a mail client removes the subscriber without a confirmation page, and that the removal is written to the suppression list and the audit log. Done means a test unsubscribe through the header changes the subscriber status and blocks later sends to that address.
Test with seed mailboxes
Send the same campaign to a set of seed mailboxes across the major providers your audience uses, including Gmail and Yahoo accounts, and review inbox placement, the authentication results in the message headers and how the unsubscribe control appears. Fix any failures in the records or templates and repeat the test until results are consistent. Done means every seed mailbox shows passing authentication, the unsubscribe header is present, and the placement results are documented for sign-off.
Monitor complaints and bounces before scaling
Start with a limited audience drawn from your most engaged subscribers, then watch complaint and bounce rates, DMARC reports and the suppression list after each send. Configure the platform to process hard bounces and complaints automatically, and set a documented threshold that pauses sends when a figure moves past it. Done means the first sends stay within the thresholds you agreed, bounce and complaint handling runs without manual intervention, and the team has approved the next volume step in writing.
Confirm the timeline with your partner
No durations for this rollout are supplied on this page, and the time each step takes depends on DNS change control, the sending service and the number of domains involved. Ask your implementation partner for a fixed-scope timeline with named milestones, the owner of each dependency, and the evidence that closes each step. Done means the written scope lists every step above with an agreed deliverable and a responsible party.
Evidence auditors and mailbox provider reviews ask for
This table maps each piece of evidence that auditors and mailbox provider reviews commonly request to the component that produces it. Use it to plan what your platform must log and export before a review begins, and to see which records come from listmonk, Mautic, the sending service and DNS. DeployOpen prepares and documents this evidence, but independent auditors and mailbox providers make the final judgments.
| Evidence item | Produced by | What reviewers check | Where it usually goes missing |
|---|---|---|---|
| DNS records and DMARC aggregate reports | DNS management and the DMARC report receiver | SPF, DKIM and DMARC records for each sending domain, and whether sending sources align with those domains | Sending subdomains that were never added to DMARC monitoring, or reports that nobody reviews |
| Sending service configuration exports | Sending service dashboard or API (for example, Amazon SES or your own MTA) | Verified domains, DKIM signing status, sending limits and any configuration set used for bounce or complaint events | Settings changed in a console with no saved export or change record |
| Unsubscribe endpoint test results | listmonk or Mautic unsubscribe handling, tested by the operations team | One-click unsubscribe headers present on bulk messages and the endpoint honors requests without extra steps | Headers added in a template but dropped by a transactional path or a relay |
| Suppression and bounce logs | listmonk campaign and bounce analytics, Mautic reports, and sending service event feeds | Hard bounces and unsubscribes are suppressed from later sends, with timestamps | Bounce processing that runs only manually or is not retained long enough to show history |
| Complaint rate dashboards | Sending service complaint metrics and the campaign analytics in listmonk or Mautic | Spam complaint rates tracked per campaign and per domain, with actions taken when they rise | Complaint data split across tools so no single trend line exists |
| Change records for list imports | Import logs in listmonk or Mautic, plus your ticket or change system | Who imported which list, when, from what source, and whether double opt-in was applied | Bulk CSV imports run by one person with no recorded source or approval |
| Consent records | Subscriber opt-in records and list settings in listmonk or Mautic, with proof stored outside the sending tool | Evidence that each address opted in or was otherwise permitted to receive bulk mail | Opt-in timestamps and form details overwritten or missing after a migration |
What the platform alone does not satisfy
Installing listmonk or Mautic gives you sending, lists and templates, but several requirements that Gmail and Yahoo enforce sit outside the software. These cards cover the gaps your team, your DNS provider and your sending service must close, and the checks that show whether they have.
DNS records stay outside the platform
Neither listmonk nor Mautic publishes SPF, DKIM or DMARC records for your domain. Those records live with your DNS provider and are set by whoever controls the zone. Before go-live, confirm that the sending domain has an SPF record that authorizes your sending service, a DKIM key that the service signs with, and a DMARC policy whose domain aligns with the From address. Check each record with an external lookup tool, not only with the platform's test send.
Inbox placement is not guaranteed
Meeting the bulk sender rules is a condition for consideration, not a promise of delivery. Mailbox providers still weigh reputation, content, engagement and history when deciding between inbox, spam and rejection. Treat authentication as the entry requirement and track placement through seed tests and provider postmaster data, since the platform reports only what it sent and what the receiving server accepted.
IP reputation belongs to the sending service
When listmonk or Mautic relays through a shared sending service, the IP addresses that reach Gmail and Yahoo belong to that provider, and so does much of their reputation. Ask the provider whether you get a dedicated or shared pool, how it isolates your traffic from other tenants, and what it does when another customer triggers blocks. The platform cannot change any of this, so the contract and the provider's sending practices decide it.
List acquisition is an upstream problem
A self-hosted platform will send to any address you import, including addresses bought, scraped or carried over from old systems without proof of consent. Complaint rates rise quickly when those addresses reach the list. Use double opt-in on public forms, record the source and timestamp of each subscription, and review imports before they reach a live list. Those controls sit in your forms, your import process and your governance rules.
Complaints need a monitored process
The one-click unsubscribe header and the spam rate threshold only work if someone reads the complaints and acts on them. Assign an owner for the abuse mailbox and the feedback loop reports, set a rule that suppresses any address that complains or bounces hard, and review complaint trends after each send. Ask your implementation partner to document this procedure as part of the runbook, so it does not depend on one administrator.
Questions buyers ask before hiring help with bulk sender authentication
What does bulk sender authentication work cost and what drives the price?
Cost is set by the written scope, not by a list price, and DeployOpen does not publish one. The main drivers are the number of sending domains and subdomains, the sending volume and number of distinct senders (newsletters, campaigns, transactional streams), whether the sending service is already configured, and how many mailbox provider problems have to be diagnosed. Ask any partner to quote one-time work (DNS records, DKIM key setup, DMARC policy rollout, unsubscribe header configuration in listmonk or Mautic) separately from recurring work (monitoring, DMARC report review, retainers), and to state which sending service they assume and who holds its account.
How long does bulk sender setup take, and what changes the timeline?
The timeline depends on how many domains and streams need changes, how quickly DNS changes can be made and verified, and whether the sending service and list data are in order. A simple single-domain setup moves faster than a multi-brand estate with several senders, because each domain needs its own alignment checks and DMARC policy steps. Policy tightening is usually staged over time, so ask the partner to show the phases in the written scope and which ones depend on your team's review or on mailbox provider behavior that cannot be scheduled in advance.
What does our team need to supply before a partner can start?
Three groups of access and decisions are needed before work begins:
- DNS access, or a named person who can publish records for each sending domain, including the TXT records for SPF, DKIM and DMARC.
- An account with the sending service (such as Amazon SES or another SMTP provider) with rights to create sending identities, read sending statistics and manage bounce and complaint notifications.
- Named list owners who confirm which subscriber lists are opted in, which streams are marketing and which are transactional, and who approves changes to sender identity.
Ask the partner to confirm this list in the written scope so that delays do not appear later in the project.
Can our own engineers do bulk sender authentication without a partner?
Many teams can complete the basic records themselves, because SPF, DKIM and DMARC are published as DNS records and listmonk and Mautic both work with SMTP sending services. Where it usually fails is in the details: DKIM signing keys not matching the sending service, SPF lookups exceeding limits, From domains that do not align with the signing domain, one-click unsubscribe headers missing or not honored, and bounce and complaint handling that is not wired back to the lists. Ask any partner to show how it will test each stream against mailbox provider requirements before and after the DMARC policy changes, and whether that testing is part of the fixed scope.
Does a fixed-scope engagement include monitoring after launch?
It depends on how the scope is written, so check it line by line. A fixed-scope engagement usually covers the agreed configuration and deliverables, such as records published, DMARC reporting set up, unsubscribe headers verified and a handover document. Ongoing monitoring of DMARC reports, complaint rates, bounce trends and configuration drift is normally a separate retainer, which DeployOpen offers for support and continuous work. Ask the partner to state in writing which monitoring tasks are in scope, who receives alerts, how long support runs after go-live, and what the client's team is expected to do.
Which sending service choice changes the work the most?
The sending service determines how authentication is configured and who owns the sending identity. A self-hosted listmonk or Mautic instance typically hands mail to an external SMTP provider or an MTA you operate, so the DKIM keys, return paths and feedback loops live with that provider. Choosing your own MTA adds work for IP reputation, warm-up and bounce handling, while a managed service moves some of that work to the provider but adds a third-party processor to your compliance records. Ask any partner to document which service they assume, what that service requires from your account, and what it does not handle for you.
Which compliance evidence does the engagement leave behind?
The useful deliverables are configuration records rather than certificates: DNS records as published, DKIM selectors and key ownership, DMARC policy history, unsubscribe header settings in each list or template, and bounce and complaint handling logs. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations, and mailbox provider requirements are not a certification. Ask the partner which evidence will be handed over, in what format, and how it maps to your internal sender policy and to any anti-spam obligations you carry in your jurisdiction.
Is a partner able to take over an existing self-hosted sending setup?
Yes, takeover work is common, but it begins with an assessment of what is already live. A partner would review existing DNS records, sending service configuration, list opt-in history, unsubscribe handling and recent bounce and complaint figures before proposing changes. Because existing senders may already be in use, changes are usually sequenced so that live campaigns are not disrupted. Ask for the assessment as a separate, fixed-scope step with its own written output, so that remediation work is priced after the current state is known.
What a fixed-scope engagement on sender authentication includes
A fixed-scope engagement on sender authentication starts with a written configuration of listmonk or Mautic against the sending service you choose, not with DNS changes alone. The statement of work should name the platform version, the sending path (for example, an SMTP relay or an API-based provider), the sending domains and subdomains, and which messages travel through each stream. DeployOpen can configure the SMTP settings, bounce handling, rate limits and sender identities in listmonk, or the equivalent mail transport, sender and tracking-domain settings in Mautic, and document each setting so your team can audit it later. The engagement should also state what is out of scope, such as mailbox placement tuning, content strategy or warm-up of new IP addresses, so that the deliverables are clear before work begins. The DNS authentication plan is the second deliverable. It should list every SPF, DKIM and DMARC record to be published or changed, the owner of each DNS zone, the order of changes, and the monitoring that confirms alignment after each step. Ask for a staged DMARC policy path, starting from a monitoring-only policy and moving to enforcement only after aggregate reports show that legitimate streams pass. Unsubscribe testing should cover the one-click unsubscribe header and the visible unsubscribe link, tested against real list and campaign settings, with results recorded per platform. The evidence pack then gathers the configuration exports, DNS records, test results and runbooks, and handover transfers ownership to your operations team. DeployOpen does not guarantee inbox placement or issue any certification of compliance, so ask for these outputs to be described as evidence for your own review and for any assessment you commission.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted listmonk or Mautic deployments inside your own infrastructure, including the DNS, sending service and mailbox provider settings that decide whether bulk mail is accepted. We agree the scope in writing first, then build and test the authentication and unsubscribe setup against your actual sending domains and volumes.
How we scope
- Inventory every sending domain, subdomain and stream that will carry newsletters or campaigns.
- Confirm which sending service, such as Amazon SES or your own MTA, relays the mail and who controls its DNS.
- Agree in writing which DNS records, headers, bounce handling and monitoring items are in the fixed scope.
How we build
- Configure SPF, DKIM and DMARC records for each sending domain and check that alignment passes in test sends.
- Set the one-click unsubscribe headers in listmonk or Mautic and verify they work through the chosen sending service.
- Wire bounce and complaint processing so suppression lists update and spam complaint rates can be watched.
How we hand over
- Deliver a written record of DNS entries, DMARC policy steps, header settings and the test results behind them.
- Document the runbook for adding a new sending domain, rotating DKIM keys and responding to complaint spikes.
- Train the named operators on the dashboards and reports they will check after go-live.
How we support
- Ongoing support, upgrades and monitoring are available as a retainer that you agree separately from the build.
- Review DMARC aggregate reports and authentication results on a schedule set in the retainer.
- Re-test authentication after listmonk, Mautic or sending service upgrades, and after any DNS change.
