Out-of-Office Not Sending? Fixes

Why is your out-of-office reply not sending? The real causes

You send an out-of-office reply, press send — and nothing happens. You check the inbox, the calendar, the logs… silence. The message isn’t blocked by spam filters. It’s not even about content. It’s about how your server delivers mail.

Out-of-office replies fail not because of a dodgy subject line or a spam trigger. The real issue is usually a misconfigured delivery path: a broken DNS record, a server ignoring auto-replies, or an email system that explicitly disables them. Even a single missing SPF tag can stop automated responses before they leave your inbox.

Here’s what you need to know: your message is fine. The problem isn’t the content — it’s how your mail server handles incoming mail and replies. Whether you’re using a custom domain or a hosted provider, these hidden settings dictate whether your auto-reply ever gets sent at all.

Key takeaways

Out-of-office replies typically fail due to server-side delivery rules, not spam filters.
Missing or incorrect DNS records (like SPF, DKIM, or MX) can block automated responses.
Auto-replies are often disabled by default on shared or corporate mail servers, especially in custom domain setups.

Is your out-of-office not sending because of sender policy blocks?

You might not be getting your out-of-office reply because your mail server or recipient’s policy blocks auto-replies from external senders. This is common when replying from shared mailboxes, forwarded domains, or when a server assumes auto-replies are part of a spam loop. To fix it, check if your sender policy or spam filter is filtering these replies — especially if sent to multiple recipients. Some organizations disable auto-replies entirely for external or team addresses.

Why auto-replies get blocked by sender policies

Many email systems, especially in corporate or shared environments, block auto-replies from external sources to prevent spam loops and abuse. If your out-of-office is triggered by an email from a shared mailbox, team address, or a forwarded domain, the server may not allow a reply at all — even if you're the original recipient. This is by design: allowing auto-replies from every incoming message could lead to infinite loops, especially in mailing list or broadcast scenarios.

Even if your mail server supports auto-replies, recipient domains might quietly drop them based on their internal rules. For example, Gmail and Microsoft 365 often suppress auto-replies that appear suspicious or sent to too many addresses at once. According to RFC 3834, auto-replies should be marked and limited to avoid flooding; when they’re not, they’re often flagged or discarded.

Shared or forwarded domains are common culprits

If you use a team email like [email protected] or a domain you don’t own, your server may not be allowed to send outgoing auto-replies. Many organizations disable auto-replies on shared or forwarded inboxes because they can’t guarantee message integrity or accountability. If someone else sends you an email from that address, even you can’t reply with an out-of-office — the server treats it as a potential bypass of sender policies.

Let’s say you’ve set up a vacation auto-reply on a mailbox that’s been forwarded via a third-party service. The forwarding server might strip or block the auto-reply headers entirely, or it might be marked as low-trust due to a misconfigured domain. This is why setting up your own domain with proper DNS records is important — it ensures your mail flow is predictable and respected by other servers.

With Unifiedesk, you can set up a fully controlled environment for your email. Whether you're using a custom domain or managing a team mailbox, our system ensures auto-replies work consistently through proper custom domain setup and JMAP-based delivery. We support out-of-office replies on personal and shared mailboxes, with no auto-reply suppression based on sender policies — because you control your data and your rules.

How SPF and DKIM affect out-of-office replies

Out-of-office replies often fail because your mail server's SPF record doesn’t include your sending IP, or your DKIM signature is missing or broken—leading to silent rejection by recipient domains. Many modern email providers reject replies without valid DKIM signatures, and SPF errors can block the message entirely. If you're using a custom domain with a self-hosted or third-party mail server, these records must be correct or your automatic replies won’t send at all.

SPF: Your sending IP must be in the record

SPF (Sender Policy Framework) acts like a whitelist. If your mail server’s IP isn’t listed in your domain’s SPF record, incoming messages from you may be accepted—but your out-of-office replies, sent by the server itself, will likely be rejected by recipients. The reply may never leave your server, or it may be silently dropped. Always verify that your SPF record includes your mail server’s IP address, and avoid common mistakes like too many DNS lookups or incorrect mechanisms.

The RFC 7208 defines SPF exactly this way, emphasizing that a valid sending domain must explicitly authorize each IP used for outbound mail. This includes system-generated messages like oof replies.

DKIM: Signature required by many domains

DKIM signs every outbound email—including automatic replies—with a cryptographic stamp that verifies it came from your domain. If your server isn’t signing outbound messages correctly, or if the signature is invalid, recipients may flag the reply as forged or spam. Some domains, especially large providers like Gmail and Outlook, require a valid DKIM signature for any automated response to be accepted.

Even if SPF passes, a missing or broken DKIM signature is a common reason out-of-office replies fail. This failure happens quietly—no bounce, no error message. You’ll think the reply sent; the recipient never saw it. Check your mail server’s DKIM configuration regularly, especially after updates or migrations.

If you’re using Unifiedesk, DKIM signing is handled automatically and enforced on all outbound mail, including out-of-office replies. Our system ensures every message carries a valid signature, so you don’t need to manually manage DNS records for DKIM. For domains hosted with us or self-hosted with our platform, this is part of standard security.

Let’s be clear: SPF and DKIM aren’t optional for reliability. They’re part of the email foundation. When your out-of-office replies stop, check both records—not just SPF, not just DKIM, but how both work together. A single misconfiguration can break automation.

Check your mailbox settings: Is auto-reply enabled?

If your out-of-office reply isn’t sending, the most common fix is ensuring it’s turned on in your mail settings. In Unifiedesk, go to Settings > Mail > Out of Office and make sure the toggle is enabled. Verify the start and end dates are correct, and that the reply is set to send only during your scheduled window. Also check that the message isn’t empty, too large, or contains malformed HTML that could block delivery.

Confirm auto-reply is turned on in Unifiedesk

Go to Settings > Mail > Out of Office.
Ensure the “Enable out-of-office reply” toggle is set to On.
If it’s off, turn it on and save your changes—you can’t send replies without this enabled.

Review timing, message content, and configuration

Check that your start and end dates are set correctly—no replies will send outside that window.
Verify the reply message isn’t empty—a blank body will usually be blocked by mail servers.
Ensure the message isn’t too large: most email systems reject auto-replies over 10–15 KB when including images or complex HTML.
Test your message in plain text mode—some HTML issues (like unclosed tags or invalid styles) can prevent delivery.
Consider that some servers, like those enforcing RFC 6218, restrict auto-replies to avoid loops and spam.

Out-of-office replies are sent at the server level, so even if the message seems correct, a misconfigured date range or invalid content can stop delivery. You can test it by sending a message from a personal account to your domain—do not rely solely on your own inbox to check.

For more about how mail works behind the scenes, check out the RFC 5322 specification on email messages and delivery. It covers how the server decides when and how to respond—without it, even a perfect reply would get ignored.

Fix: Out of office not working on custom domains?

Out of office replies fail on custom domains when your DNS records—MX, SPF, DKIM, and DMARC—are misconfigured or incomplete. Even one broken record can block inbound mail, preventing the auto-reply from triggering. Let’s fix it step by step.

Check Your DNS Records

If your out-of-office reply isn't sending, start by verifying all DNS records for your domain. Mail servers reject messages if they don’t trust the sender’s identity. The most common culprits are missing or invalid SPF, DKIM, or DMARC records.

MX records must point to your email provider’s servers. If they’re wrong, mail doesn’t arrive—so no auto-replies.
SPF records tell receiving servers which IPs are allowed to send mail for your domain. Omitting the correct IP or using invalid syntax breaks delivery.
DKIM signs your outbound mail. Without a valid DKIM key, replies may be rejected or marked as spam.
DMARC policies enforce SPF and DKIM. Poorly configured DMARC can cause mail to be dropped silently.

Use tools like MXToolbox or RFC 7050 to validate your setup. A single mistake in any record can block the entire flow.

Use Built-in Tools to Generate Records

Let’s make this easy. Unifiedesk’s custom domain setup tool generates valid MX, SPF, DKIM, and DMARC records in seconds—no guesswork.

Sign in to your Unifiedesk dashboard.
Go to Domain Setup and enter your domain (e.g., yourcompany.com).
Click “Generate DNS Records.”
Copy the full records and paste them into your domain registrar’s DNS manager.
Wait 5–10 minutes—then test with Google’s Toolbox or an email tester.

If you’re using a custom domain, ensure inbound mail is accepted by Unifiedesk’s servers. Also, confirm that replies are sent from a verified IP—your domain’s DKIM key must match the signing server’s identity.

Most out-of-office failures stem from missing or misaligned DNS records. Fix those, and replies go out reliably. Once done, test with a real email from outside your domain to confirm the reply triggers.

For full control over your email, calendar, and workspace—without third-party data harvesting—try Unifiedesk’s private email with native out-of-office, secure by design.

Why your mail server doesn’t send replies to all senders

Some mail servers are configured to only send auto-replies (like out-of-office messages) to internal users, not external ones—this is a common anti-spam measure. If your out-of-office reply isn’t reaching senders outside your organization, your server might be blocking replies to domains not in your trusted list. Let’s break down why and how to fix it.

Internal-only autoreplies are a known security practice

Mail servers often restrict auto-replies to internal users by default. This prevents spammers from probing your system to confirm valid email addresses—something the Internet Engineering Task Force (IETF) acknowledges in RFC 5322 as a defensive strategy.

When you send an out-of-office reply to an external sender, it can signal that an address is active. If your server only replies to internal users, spammers can’t exploit that signal. This behavior is widely seen in enterprise systems and cloud providers.

Check your auto-reply rules and filters

You may have inadvertently enabled filters that block replies based on sender domains. Look for Sieve filter rules or auto-reply rules labeled something like “reply only to internal senders,” “deny replies to external domains,” or “sender restriction” in your email server settings.

On Unifiedesk, this behavior is enabled by default for privacy. To allow replies to external senders, go to your email settings and disable “Reply only to internal users” under Auto-reply Rules. This change applies instantly and affects only your out-of-office messages, not your inbox.

If you’re using a self-hosted setup, check the Sieve script in your mail server configuration. A rule like if address :is "from" "domain.com" { ... } may be silently excluding external emails. Remove or adjust such restrictions if broader replies are needed.

Verify your domain's DMARC policy is not too strict

If your domain’s DMARC policy is set to reject or quarantine, it might block out-of-office replies—even when they’re legitimate. These policies block emails that fail SPF or DKIM checks. If your server sends replies without proper authentication (like missing DKIM signatures), DMARC will reject the email before it reaches the recipient. Let’s walk through how to test and adjust this safely.

How DMARC can silently block automated replies

Out-of-office replies are sent by your mail server on your behalf. If the server doesn’t include a valid DKIM signature or is not authorized under SPF, DMARC sees it as unauthorized. Even if the email is correct, a strict policy won’t allow it through. This is common with self-hosted or non-standard setups where sender authentication is misconfigured.

For example, if your email system uses a different sending mechanism than your inbox (like a forwarder or relay), it may not align with the original sender’s SPF or DKIM. DMARC evaluates authenticity based on the domain and authentication chain—so even a well-intentioned reply can get blocked if it doesn’t meet the bar.

Test safely with p=none

To check whether DMARC is the culprit, temporarily set your DMARC record to p=none. This tells receiving servers to log failures but not block them. It’s a standard way to troubleshoot without disrupting delivery.

Modify your DNS record to set v=DMARC1; p=none; rua=mailto:[email protected] and wait 24–48 hours. Then send a test OOO reply to an external address. Check if it arrives. If it does, your original policy was too strict.

Remember: this test is temporary. Once you confirm the setup works, you can restore a more secure policy—like p=quarantine—after ensuring your outgoing mail is properly authenticated.

For more on email authentication, see the IETF's DMARC specification (RFC 7483) or review guidelines from the Anti-Phishing Working Group. These standards help ensure your domain is trusted while still allowing automated responses.

If you’re using Unifiedesk, outbound mail is signed with DKIM and properly authenticated. Your OOO replies will send reliably—no need to tweak DMARC unless you’re using a different mail system. For full control and privacy, consider setting up a custom domain with Unifiedesk’s automated setup tools. Set up your domain in minutes with built-in SPF, DKIM, and DMARC records that work right out of the box.

Test your auto-reply: How to confirm it’s sending reliably

You can verify your out-of-office reply is working by sending a test email from a different provider to your inbox, checking your sent folder or mail logs for the auto-response, and confirming it was delivered using tools like MxToolbox or Mail-tester.com to examine headers and delivery path. Let’s walk through it.

Step-by-step verification

Send a test email from a different provider. Use a Gmail, Outlook, or Proton Mail account to send a message to your primary email address. This simulates how a real contact will reach you and triggers the auto-reply logic.
Check your sent folder or mail logs. Look for the automated reply in your “Sent” folder or, if you're using a self-hosted or enterprise system, review your mail server logs. A logged delivery confirms the rule executed and queued the response.
Verify delivery path with MxToolbox or Mail-tester.com. Paste your email address into MxToolbox to trace the mail path and check if your MX records are correctly configured. Use Mail-tester.com to send a test message and inspect the headers—this shows whether your server signed the auto-reply and if it was accepted by receiving mail systems. This step is not for spam testing, but for validating SMTP handshake and routing.
Check headers for DKIM and SPF passes. If your email system signs messages (as Unifiedesk does), examine the headers in the test response for a valid DKIM-Signature and SPF pass. These verify the message originated from your domain and wasn’t forged. RFC 5322 requires header integrity for trust.
Confirm no filtering is blocking it. Some systems silently discard auto-replies if they trigger spam thresholds. Check your spam folder on the test account and inspect the content and subject line for red flags like “out of office” repeated in large text.

Common pitfalls to check

Make sure your auto-reply isn’t limited to one per day. Some providers (not Unifiedesk) throttle these to prevent spam.
Ensure your inbox isn’t full—some systems won’t send auto-replies if storage is exceeded.
Check if the reply is set to send only to internal users. If so, it won’t reach external addresses.

Never assume the auto-reply sent—verify it at every step. A missed reply can cost you a client, a contract, or a personal connection.

If you're on a self-hosted system, Unifiedesk’s self-hosted option gives you full visibility into logs and mail flow, so you can debug replies without relying on third-party dashboards. For managed email with end-to-end encryption and reliable delivery, Unifiedesk Mail handles DKIM, SPF, and outbound routing with precision—no guesswork.

Unifiedesk’s automated out-of-office: How it works

When your out-of-office reply isn't sending, it’s often due to authentication failures, spam filtering, or delivery retries not being handled properly. With Unifiedesk’s hosted platform, auto-replies are sent only after incoming mail is verified via SPF and DKIM, and DMARC policies are enforced—meaning your reply goes out only when the sender is legitimate. End-to-end encryption secures every message, including auto-replies, so your status is private and cannot be intercepted.

Authentication first: Why your reply only sends when it should

Let’s be clear: your out-of-office reply is not sent until the incoming email is validated. Unifiedesk checks SPF (sender policy framework), DKIM (domain-based message authentication), and enforces DMARC policies before triggering any auto-responses. This prevents bots and spoofed emails from triggering replies, which is how most unwanted auto-replies get sent.

Think of it like a secure gate: only verified senders pass through. This is an industry-standard approach—RFC 7208 (DMARC) defines this behavior—and it’s why services like Google and Microsoft also require such checks. When misconfigured, SPF or DKIM failures can block incoming mail entirely, which means no auto-reply even if it’s set.

Handling failures: Retry logic and delivery safety

If a reply fails to send—say, due to a temporary DNS issue or spam filter block—Unifiedesk doesn’t give up. It applies smart retry logic, attempting delivery with increasing delay. This reduces the chance of your reply being marked as spam simply because it was sent too soon after a bounce.

On the hosted platform, all messages, including auto-replies, are end-to-end encrypted. Your out-of-office status is protected from third-party access, just like your inbox. For teams using self-hosted Unifiedesk, data remains under your control, with AES-256-GCM encryption applied at rest, and TLS used for transit.

If you're managing your own domain, setting up your MX, SPF, DKIM, and DMARC records is straightforward. Unifiedesk generates the correct records for you in real time—no guesswork. Once configured, your auto-replies work reliably. You can also manage them via your calendar or AI assistant for dynamic updates.

Need full control? You can always run Unifiedesk on your own servers with full encryption and zero data sharing. Learn more at our self-hosting guide.

When self-hosting, why auto-replies may fail silently

Auto-replies might not send on self-hosted Unifiedesk because a Sieve filter rule is disabled, blocked by another rule, or the mail server’s delivery queue is stalled. Even with end-to-end encryption and TLS protection, misconfiguration is the most common cause. Check your filter setup and server logs—your reply might be generated but never delivered.

Filter rules can silently override your out-of-office reply

On self-hosted Unifiedesk, Sieve filters control how messages are processed. If a higher-priority rule intercepts incoming email before the out-of-office filter runs, the reply won’t trigger. Let’s say you have a rule that moves all emails from a specific domain into a folder—this can bypass the auto-reply logic. Always verify that your OOO rule has the right priority and isn’t masked by earlier rules.

Use the self-hosted admin interface to audit your rules. Look for any that consume or redirect mail before the OOO condition. You can test it in practice by sending a test email from another account and reviewing the log output.

Check delivery queue status and server logs

The reply might be generated but stuck in the delivery queue. On self-hosted setups, mail delivery depends on Postfix or similar backend services. If the queue is stalled—due to a missing DNS resolver, network timeout, or a failed outgoing connection—no replies go out. Check your mail server’s status with mailq or your admin dashboard.

Logs are your best guide. The self-hosted deployment guide details where to find them (typically under /var/log/mail.log or via a web interface). Look for entries like “generating out-of-office reply” or “sending response to” to confirm the system processed the request. If you see the reply being generated but no delivery, investigate network settings, relay configurations, or firewall rules.

For reference, RFC 5457 (which defines auto-replies) confirms that servers should only send them if the envelope sender is valid and the message is accepted. This helps you isolate whether the issue is with policy, configuration, or infrastructure.

Final checklist: Fix out-of-office reply not sending now

Email auto-replies rely on precise configuration. When they fail, it’s rarely one single issue—but a chain of technical checks. The most common reasons are misconfigured DNS records, disabled auto-reply settings, or overly strict DMARC policies blocking outbound messages. Always verify the basics first.

Confirm auto-reply is enabled in your email client or web interface. Some providers disable it by default.
Check your SPF record includes the IP address of your mail server. Missing or incorrect entries block outbound emails.
Ensure DKIM is signed on all outbound replies. Unsigned messages may be rejected by receiving servers.
Set DMARC policy to p=none during testing. A strict p=reject policy can prevent auto-replies from delivering.
Test with an external email account using a different provider. This avoids loopback or internal filtering issues.
Check server logs if self-hosted. Look for delivery errors, connection timeouts, or rejected messages.

Out-of-office replies should just work—when the system is set up right. A moment of configuration effort now saves hours of missed messages later.

Keep reading

Ready to put this into practice? Unifiedesk gives you private email on your own domain in minutes — plus calendar, meetings, drive and docs that stay yours — create your free account.

Frequently asked questions

Why is my out-of-office reply not sending to external senders?

Out-of-office replies may be blocked if SPF/DKIM are misconfigured, DMARC is set to 'reject', or the server is restricted to internal-only replies.

Can I send an auto-reply on a custom domain with Unifiedesk?

Yes—Unifiedesk supports custom domains with fully automated MX, SPF, DKIM, and DMARC records generated in minutes.

Does Unifiedesk block auto-replies by default?

No—Unifiedesk allows auto-replies unless configured otherwise. Server-side policies or DMARC can still block delivery.

Why does my out-of-office reply appear as spam?

It may be flagged if not properly DKIM-signed, sent to multiple recipients, or sent from a domain with poor authentication.

How do I test if my auto-reply is working?

Send an email from a different provider to your inbox and check if a reply appears within 5–10 minutes.

Can self-hosted Unifiedesk send out-of-office replies?

Yes—auto-replies are fully supported on self-hosted deployments, provided Sieve rules and DNS records are correctly set.

Are out-of-office replies encrypted in Unifiedesk?

Yes—on the hosted platform, replies are end-to-end encrypted. On self-hosted systems, messages are encrypted at rest with per-account AES-256-GCM.

What is the maximum length for an out-of-office reply?

Unifiedesk supports standard message size limits—up to 25 MB for attachments, but replies should be concise for best delivery.

Can I schedule an out-of-office reply to start later?

Yes—set a future start date in the out-of-office settings. The reply will activate automatically when the time is reached.

Why are some auto-replies sent, others not?

This usually indicates inconsistent SPF/DKIM or DMARC policies, or selective filtering rules that block replies to certain domains.

How can I check if my reply was rejected?

Check mail logs for bounces or delivery failure reports. Unifiedesk provides access to delivery status for both hosted and self-hosted setups.

Do I need to enable DMARC to send auto-replies?

No—but a DMARC policy set to 'reject' can block replies if authentication fails. Use 'p=none' during testing.